[SERVER-31493] JSON Schema incorrectly treats dotted field names as paths Created: 10/Oct/17  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Nicholas Zolnierz Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 1
Labels: mql-semantics, qopt-team, query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-39285 [FLE] Reject dotted fields names in J... Closed
is related to SERVER-30575 Please add escaping convention for do... Backlog
Assigned Teams:
Query Optimization
Operating System: ALL
Sprint: Query 2017-11-13, Query 2020-07-13, Query 2020-07-27
Participants:

 Description   

> db.test.find()
{ "_id" : ObjectId("59dcfc510d45ac010df64f5f"), "a.b" : 1 }
> db.test.find({$jsonSchema: {properties: {'a.b': {type: 'number'}}, required: ['a.b']}})
> 

There are several similar tickets, but this is meant to track the behavior specifically within a $jsonSchema validator.



 Comments   
Comment by Katherine Wu (Inactive) [ 03/Aug/20 ]

Moving back to Query backlog for further discussion on how to implement.

Comment by Nicholas Zolnierz [ 20/Nov/17 ]

Moving to Query team backlog as there's limitations with the approach described above that depend on the ability to query over dotted fields.

Comment by Nicholas Zolnierz [ 16/Nov/17 ]

david.storch, my idea was to add an optional argument to the FieldRef constructor to indicate whether the path should be expanded or not. If not, then the parse would stop here and create a single "part" with the full dotted path. Of course this would require some plumbing through ElementPath and the path-matching expressions that are used in JSON Schema. Unfortunately I think one hole in this approach is that it likely won't work after re-parsing the serialized BSON as we wouldn't be in the JSONSchema parser at that point.

Comment by Asya Kamsky [ 03/Nov/17 ]

Note from testing:

Inside "properties" 'a.b' is treated as a literal json field name 'a.b' but in "required" it's treated as a path to object a with subfield b.

db.test.find({$jsonSchema: {properties: {_id:{}}, required:['_id','a.b']}})
{ "_id" : ObjectId("59dcfc510d45ac010df64f5e"), "a" : { "b" : 1 } }
db.test.find({$jsonSchema: {properties: {_id:{},'a.b':{}}, required:['_id']}})
{ "_id" : ObjectId("59dcfc510d45ac010df64f5a"), "b.a" : 1 }
{ "_id" : ObjectId("59dcfc510d45ac010df64f5e"), "a" : { "b" : 1 } }
db.test.find({$jsonSchema: {properties: {_id:{},'a.b':{}}, required:['_id'], additionalProperties:false}})
{ "_id" : ObjectId("59dcfc510d45ac010df64f5f"), "a.b" : 1 }

Comment by David Storch [ 10/Oct/17 ]

Good find nicholas.zolnierz! This doesn't seem critical since schemas involving stored dotted field names were historically disallowed and continue to be discouraged. However, it is interesting that JSON Schema gives us a syntax for expressing certain queries over stored dotted field names. Given the internals of the matcher, I could imagine that the fix could be involved, but we should investigate.

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