[SERVER-44558] wildcardProjection not available for subtrees Created: 11/Nov/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: 4.2.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Eliott Coyac Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 1
Labels: qopt-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-13227 Add wildcardProjection warning Closed
Related
is related to SERVER-391 Support both include and exclude on f... Backlog
is related to SERVER-48897 Allow sub-field matching in Wildcard ... Backlog
Assigned Teams:
Query Optimization
Operating System: ALL
Participants:

 Description   

wildcardProjection does not work for wildcard indexes on a subtree. For example:

db.getCollection("companies").createIndex( { "representatives.$**" : 1 }, {wildcardProjection: {"representatives.niceNames": 0}} );

 Gives the error:

{
 "ok" : 0.0,
 "errmsg" : "The field 'wildcardProjection' is only allowed when 'key' is {\"$**\": ±1}",
 "code" : 9,
 "codeName" : "FailedToParse"
}

Since the doc does not mention any such restriction, I am assuming it's a bug.



 Comments   
Comment by Charlie Swanson [ 03/Dec/19 ]

eliott.coyac@gmail.com changing the wildcard indexes to avoid using the projection infrastructure would be a substantial architectural change. We use the projection infrastructure today to trim down each document to just those fields we need to care about for the index. Why invent an entirely new language/system to do this when the projection language is already built to trim down documents to the fields you need? I think this is a reasonable request, but unfortunately it is one that is pretty difficult to implement.

I have bumped up the priority of SERVER-391, I'm not sure why it was "Minor".

Comment by Eliott Coyac [ 15/Nov/19 ]

Thanks for the info

This isn't intuitive - The fact that creating a wildcard index on a field is actually creating a wildcard index on the root projected to the field. Maybe the issue can be solved without addressing https://jira.mongodb.org/browse/SERVER-391 by not making use of projection when creating a wildcard index on a field?

Also, https://jira.mongodb.org/browse/SERVER-391 is minor because it can easily be worked around through aggregation, but this can't be solved the same way. Should the severity of https://jira.mongodb.org/browse/SERVER-391 be bumped up if it becomes the crux of the issue?

 

Comment by Danny Hatcher (Inactive) [ 15/Nov/19 ]

eliott.coyac@gmail.com, effectively you are attempting to include the top-level field by specifying {"representatives.$**" : 1} but then exclude a single subfield through {"representatives.niceNames": 0}. As of right now, MongoDB doesn't have the ability to mix inclusions and exclusions for subfields. If we ever decide to implement it, we have a SERVER-391 open in our backlog. Therefore, the request here is actually more of a fundamental change in our projection semantics rather than our wildcard index implementation.

However, you are correct that this is a miss in our documentation and I have opened DOCS-13227 to address it.

Generated at Thu Feb 08 05:06:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.