1

Considering this set of data :

{
 "lstLikeUserid" : ["5992dc5725ac203acfa101e6"],
 "title" : "a title" 
},
{ 
 "lstLikeUserid" : ["6000dc5725ac203acfa101e6"],
 "title" : "another title"
}

I want to create a computed field to indicate that a user id is present in the array lstLikeUserid.

Here is the code i use which does not work :

 String userId  ="5992dc5725ac203acfa101e6";
 ConditionalOperators.Cond condOperation = 
 ConditionalOperators.when(Criteria.where("lstLikeUserid").is(userId))
            .then("true")
            .otherwise("false");
 ProjectionOperation projectOperation = 
 Aggregation.project().and(condOperation).as("like").andInclude("title");
 Aggregation aggregation
            = Aggregation.newAggregation(projectOperation);
 AggregationResults<ChannelItemEntry> result = mongoTemplate
            .aggregate(aggregation,ChannelItemEntry.class,  ChannelItemEntry.class);

The computed field "like" is always false even if the user id matches.

philippe vandenhove
  • 43
  • 3
  • Are those actually "strings"? The top one at least appears to be valid of an `ObjectId` value, which is NOT a string. What does the actual document look like when viewed from the [`mongo` shell](https://docs.mongodb.com/manual/mongo/)? Please show that here if it's any different from what you are presently showing. – Neil Lunn May 14 '18 at 09:05
  • Here is an excerpt of the document from the mongo shell : "lstLikeUserid" : [ "5992dc5725ac203acfa101e6" ], the userid is stored like a String. – philippe vandenhove May 14 '18 at 09:21
  • The code seems to disagree. What happens when you just do a simple `.find()` with the same `Criteria.where("lstLikeUserid").is(userId)`? If you don't get a document back in result, then it's actually not a string and probably is an `ObjectId` despite you trying to say otherwise. Nothing wrong with the statement, so the only problem can be your data. Even if they were strings they "should" be `ObjectId` anyway since it takes a lot less to store than the "string". And also probably is meant to refer to another collection object which actually IS `ObjectId` anyway. – Neil Lunn May 14 '18 at 09:27
  • Good test, I just tested the find with Criteria.where("lstLikeUserid").is(userId) and it works. – philippe vandenhove May 14 '18 at 09:38
  • The query generated is not the same. It's $eq operator with a projection and $match operator with a simple find. – philippe vandenhove May 14 '18 at 09:48
  • Hmm. What about `Aggregation.project().and("like").applyCondition(condOperation)` Don't have an IDE open right now, but I just skimmed some code of mine and that's kind of how I have it. I know the test I asked you to do is different and was simply trying to see if the data actually was a string. It is of course. I think this is actually about how the `$cond` is coming out in the projection, so that line I gave should be correct, but I just cant run a test in Java right now. – Neil Lunn May 14 '18 at 09:49
  • No, it does not solve the problem. – philippe vandenhove May 14 '18 at 10:11

1 Answers1

0

You should use $unwind on the lstLikeUserid field prior to filtering it.

Arthur
  • 38
  • 6