|
Moving back to Query backlog for further discussion on how to implement.
|
|
Moving to Query team backlog as there's limitations with the approach described above that depend on the ability to query over dotted fields.
|
|
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.
|
|
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 }
|
|
|
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.