Final exam question 2 wording

“Indexes can be walked backwards by inverting their keys in a sort predicate.”

What is meant by “inverting their keys”?

Example index: {a:1, b:1}

This?:
{
$sort: {
a: -1,
b: -1
}
}

or this?:
{
$sort: {
b: 1 // or -1
a: 1 // or -1
}
}

I know the first option walks the tree backwards, but the answer is either true or false depending on what “inverting the keys” means. (I would think “inverting the index sort key values” or something would be more clear, although more wordy.

@James_31476

Actually, you should be able to work this out for yourself. Think about how the index is formed. The query analyzer cannot change the direction (ascending or descending) of individual fields within a compound index. It can only walk the tree “backwards”. Consider a simple “thought experiment” here. Let’s suppose that that we have an index (a:1, b:1) on the fields “a” and “b”, where the values are a:A1,b:B1 a:A1,b:B2 a:A1,b:B3 a:A1,b:B4 a:A2,b:B1 a:A2,b:B2 a:A2,b:B3 a:A2,b:B4 ... a:A4,b:B4 – basically, a & b take the four possible values A1 - A4, and B1 - B4. Then the index will look something like

A1,B1  A1,B2  A1,B3  A1,B4 ... A4,B1  A4,B2  A4,B3  A4,B4

Now this index can be used in its original direction (of course) but it can also be read “backwards” from A4,B4 to A1,B1 right? Which is the equivalent of the index (a:-1, b:-1). But it can’t be read A4,B1 A4,B2 A4,B3 etc. which would be the index (a:-1, b:1) because the index doesn’t go in that direction, and the analyzer can’t “reach into” the actual index to parse it – it only reads it.

Thanks for the detailed response DHz!

I understand how indexes can be walked, but my question had more to do with how the question considers the phrase ‘inverting their keys in a sort predicate’ to be defined.

In short, given Index = { a: 1, b: 1} is “inversion” defined as:
A) { b: 1, a: 1 }
or
B) { a: -1, b: -1 }
or maybe even
C) { b: -1, a: -1 }
for this question?

Once again, I KNOW (B) is the only way that the index can be walked backwards, but if the author of the question considers inversion to be (A) or ( C), then I will get it wrong. Does the QUESTION consider inversion to be (A), (B) or ( C)?

I have a sneaky suspicion I’m just overthinking the phrase and probably suck at wording my question as well, but I also hate to assume otherwise!

1 Like

@ James_31476

OK. So the issue for you is whether we (the curriculum team) are asking a straightforward understandable question, or are trying to trick you? I assure you, both in this course and all our courses, that the there are no trick questions, nor ones that rely on you figuring out some semantic twist. The only objective here is to help the students understand the underlying structure of MongoDB and to help them diagnose and fix real operational problems. So you’re good to go here. Good luck.

1 Like

Thanks for your patience DHz!

The issue of the curriculum team’s motives are explicitly not the issue for me, rather it was “what is the question’s definition of ‘inverse’”, as I’ve so poorly tried to communicate. (Having been trained through two degrees in mathematics, I don’t like to make assumptions on what the definitions of certain words are!)

Nonetheless, I poked through the docs and found this page (https://docs.mongodb.com/manual/tutorial/sort-results-with-indexes/index.html)
which uses the “inverse” terminology with an example, and thus gives me a concrete definition of what MongoDB considers “the inverse of an index”, quote:

“For a query to use a compound index for a sort, the specified sort direction for all keys in the cursor.sort document must match the index key pattern or match the inverse of the index key pattern. For example, an index key pattern { a: 1, b: -1 } can support a sort on { a: 1, b: -1 } and { a: -1, b: 1 } but not on { a: -1, b: -1 } or {a: 1, b: 1} .”

That’s really all I was looking for. (Again, I already knew how to walk it backwards, I just needed concrete verification that “inverse” meant what I thought it did.)

Anyways, thanks again for your patience! I actually very much appreciate the curriculum team’s hard work in making these courses and preparing the download materials and vagrant environments, etc. Usually I have to go to some third-party site like Udemy or Pluralsight and rely on courses that are a year or two old and maybe deal with a bunch of other fluff filler material in the course, but it is SO refreshing to find mongodb university and know that the courses are going to be up to date and are being constantly refined. In fact, though there are other competitors in your space, I think it’s you guys and mongodb university that’s really going to set MongoDB apart and give it the edge, because people won’t use technology they don’t understand and that’s hard to learn about, and don’t want to have to dig through archaic docs just to learn how something works (like walking an index backwards!). The more MongoDB helps make it easier for others to understand how to use its product, the more successful it (and we, your users) will be. So, thanks! And you can close this thread now if you want :slight_smile: