- Newest
- Most votes
- Most comments
Not sure what you mean by unintended loophole in this context, but your tests validate what the DocumentDB documentation states.
To use a sparse index that you have created in a query, you must use the $exists clause on the fields that cover the index. If you omit $exists, Amazon DocumentDB does not use the sparse index
means that if you have a sparse index and you use $exist: true
condition the index will be used, which is what happens. Maybe the documentation could explicitly state $exist: true.
On the other hand, DocumentDB does not support using the index with $exists: true
if the index is not sparse, and your tests demonstrate it, as pointed out by:
Amazon DocumentDB does not currently support the ability to use indexes with the $ne, $nin, $nor, $not, $exists, $distinct, and $elemMatch operators. As a result, utilizing these operators will result in collection scans
Relevant content
- asked 4 years ago
- asked 2 years ago
- asked 2 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 6 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
Yes, it would be better if the documentation was made clearer but combining these 2 pieces of information in one place:
"Amazon DocumentDB does not currently support the ability to use indexes with the $ne, $nin, $nor, $not, $exists, $distinct, and $elemMatch operators. As a result, utilizing these operators will result in collection scans. Except in the case of sparse indexes which can be used for queries containing a
$exists: true
clause".I am still interested in knowing why this behaviour exists though. As I mentioned above, it doesn't make sense that the sparsity of the index affects whether or not it can be used in a query containing
$exists:true
. This is what I meant by 'unintended loophole'. Because it doesn't make sense, I wondered if this was intentional behaviour. And if not, someone might come along and fix it and suddenly sparse indexes stop working for particular queries.