Certification question


I suppose an issue with this question, or, i don’t understand the answer:

For me, it seems the request was covered by the index.

I make this test on my local using the following index:
{first_name: 1, birthday:1}

And the result is:


For my test, this is an example of documents of my DB:

Someone can confirm me the issue or explain me the result?
Thank you :slight_smile:

Hi @Yann_05178,

At a quick glance it looks tricky, but if you look a bit closer you will notice that it’s returning/projecting user.description which is not part of the index and as a result it will not be covered.


I am not sure, the request is performed on the field “user” (which is in the index), then the sort on the date (second key of the index) then we project only the field “user”… So the description should not impact the request… :confused: Or i miss something…

So user is an object that contains a sub-document. If you specify user:1 in a projection, it will include all the fields. In order for the query to covered, you must specify login and/or date because those are the only two sub-fields that are part of the index, description is not. Makes sense? :slight_smile:

My bad… Yes i understand, thank you :slight_smile:

:slightly_smiling_face: :+1:

so, is that the right answer ?
“MongoDB will need to do a table/collection scan to find matching documents”

No. Have you read the thread in its entirety?

how it will use the index(scan) to return the “user.description” field, if this field is not in the index?

As per the answer, myIndex is used here:

so, the index will be used to filter “user.login”, not to return the fields of the array “user” that is it?

That’s right. It will be used to find the documents where user.login begins with “ir”, but it won’t be used for sorting or projecting.

thanks for you pattience, i didn’t know the mongodb could use index to do some parts of the process and others not, i will read more about.

Also read more on Covered Queries. And I would suggest that you register for the MondoDB courses, some of them cover indexes in some detail.

1 Like

thanks again, i will do that

Regarding this, why exactly isn’t the optimized sort query wrong. I expected it to be able to sort on the index?

You meant why “is”? It can’t utilise the index on the sort because the query predicate isn’t an equality condition.

1 Like

ohh, I’m dumb. You get so deep into keys and orders you forget the simple things. Got it now.
And yes I meant why is that answer wrong. (I obviously got that wrong). But I get it now. If there was equality on the user.login then the query would have been sort optimized I assume

That’s right!

But for the exam, bear in mind that there is another rule… this query will use the sort index:

find( {"user.login": /^ir.*/}, <project>).sort("user.login": 1)

Because of an overlapping prefix?