Ch 1 - projection returning empty dictionary

I’m on the computing fields lab. I’ve converted the title field into an array, I’ve set up a $cond to return single element arrays and I $$REMOVE the other titles. This latter leaves an empty dictionary:

  {},
  {},
  {},
  {},
  {},
  { 'the title': 'Cinderella' },
  {},
  {},

(I also removed the _id field)

There is obviously something wrong. Could I please have a hint? I didn’t include the code as requested.

click on belove blurred area

you can use spoiler tag ; click on gear icon :gear: and select “Blur Spoiler” :wink:

it is hard to understand what are you trying, especially with that “$$REMOVE”

if the title array only has one element, assign that element to the created field otherwise remove it from the projection

I would recommend reading the Aggregation Pipeline Operators documentation to see if there might be an operator that will help you determine how many elements are in an array.

You could also add a stage to check to see if a field exists from the results of the pipeline up to that point.

I’m not sure how much of a hint you want, but the above are some ideas of where to go from here.

the devil is in details, in this case, in the implementation of your logic. your use is partially correct; you really return documents with single-word titles. you just need to think about what each stage is doing, what each returns, and most importantly what you need after each stage.

Do not haste in the course. Do not try to finish the course in one day. give short/long breaks as you need. “Aggregation” might become all your life, so try to understand it better. it is easy and fun to use, but not a forgiving one if you ignore the basics.

1 Like

I worked it out using a different operator, but I still want to understand what was wrong previously. How can I post the code? Hide details? Blur spoiler? Can both yourself and Doug Duncan see it?

thanks

If you put your code into a spoiler block then it’s blurred and anyone who wants to see the code will then have to click on that section to see the code. It just adds another step to be able to see the code, so if someone is working on this lab they can read the text, but not see the example code until they are ready to click on things to make them visible.

OK, thanks. Here it is:

var pipeline = [
{
‘$project’: {
‘my title’: { ‘$split’: [’$title’, ’ ‘] }
}
},
{
‘$project’: {
‘single word title’: {
$cond: {
if: { ‘$eq’: [{ ‘$size’: ‘$my title’ },1]},
then: {’$arrayElemAt’: [ ‘$my title’, 0 ]},
else: “$$REMOVE”
}
}
}
}
]

What I don’t understand is why the $cond block returns empty dictionaries when the size expression is false. I’d expect it to not return anything and effectively filter out the fields with more than 1 array element.

The $$REMOVE aggregation variable is going to remove the field from the returned document if the condition is false in your code, which is what you are seeing. It will not remove the document itself. This is why I recommended adding a stage after this to determine if the field you were looking for existed in the results and filter out any where it didn’t exist.

2 Likes

Doug tells you about “why are there empties”.

Now the mistake in your thinking of aggregates: not all stages are suitable for what you may think would achieve. plus it may affect performance badly depending on how you use them.

  • “project” stage results in passing only the fields you put into it, plus “_id”. it is not intended for document removal (yet it can do as you experienced).
  • mainly, “match” is responsible for filtering documents by “conditions”
  • “addField” is the main one to create a new field form within
1 Like

Great, thanks guys. I now understand stages better and the difference between $project and $match.

Doug tells you about “why are there empties”.

Now the mistake in your thinking of aggregates: not all stages are suitable for what you may think would achieve. plus it may affect performance badly depending on how you use them.

  • “project” stage results in passing only the fields you put into it, plus “_id”. it is not intended for document removal (yet it can do as you experienced).
  • mainly, “match” is responsible for filtering documents by “conditi

Doug tells you about “why are there empties”.

Now the mistake in your thinking of aggregates: not all stages are suitable for what you may think would achieve. plus it may affect performance badly depending on how you use them.

  • “project” stage results in passing only the fields you put into it, plus “_id”. it is not intended for document removal (yet it can do as you experienced).
  • mainly, “match” is responsible for filtering documents by “conditi 1

Doug tells you about “why are there empties”.

Now the mistake in your thinking of aggregates: not all stages are suitable for what you may think would achieve. plus it may affect performance badly depending on how you use them.

  • “project” stage results in passing only the fields you put into it, plus “_id”. it is not intended for document removal (yet it can do as you experienced).
  • mainly, “match” is responsible for filtering documents by “conditi 2

@rchyh_rchyhc did you have a question?

or fell victim to the page design? Posting is a bit different than many other sites :sweat_smile: