[SERVER-37503] Support $type with wildcard index Created: 05/Oct/18  Updated: 29/Oct/23  Resolved: 15/Oct/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.1.4

Type: Bug Priority: Major - P3
Reporter: Yuta Arai Assignee: Yuta Arai
Resolution: Fixed Votes: 0
Labels: afz
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-36198 Enable $** index builds by default in... Closed
is depended on by SERVER-37432 Re-enable aggregation_wildcard_fuzzer... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

db.c.createIndex({"$**":1})
db.c.find({x: {$type: "object"}}).explain()

Sprint: Query 2018-10-22
Participants:

 Description   

When running a $type query with a wildcard index, it currently will try to use the index leading to an incorrect result.



 Comments   
Comment by Githook User [ 15/Oct/18 ]

Author:

{'name': 'yarai', 'email': 'yuta.arai@10gen.com', 'username': 'yarai'}

Message: SERVER-37503 Support $type with wildcard index
Branch: master
https://github.com/mongodb/mongo/commit/c2b08fc7c1228402663d166074176c314664befe

Comment by Ian Boros [ 08/Oct/18 ]

I suspect {$type: "object"} will just produce bounds of [{}, []]. As part of Bernard's DISTINCT_SCAN work and my work to support {$ne: null} queries, we're adding logic to expand these bounds into MinKey MaxKey. This problem might just go away once either of those are merged (though we'd still have to write a test for it).

Comment by James Wahlin [ 08/Oct/18 ]

Rather than ban we should consider making $type work for wildcard indexes. I suspect it will work correctly now for types other than "object". For type "object" we could consider handling in the same manner that we do arrays for regular indexes, which is to scan the index from MinKey to MaxKey (for $** we would scan path* + MinKey/MaxKey on the value) and perform an INEXACT_FETCH to determine whether a document matches.

Generated at Thu Feb 08 04:46:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.