[SERVER-32160] provide warning when _id is not in list of properties and additionalProperties is false Created: 04/Dec/17  Updated: 30/Oct/23  Resolved: 15/Oct/21

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 5.1.0-rc1

Type: Improvement Priority: Major - P3
Reporter: Asya Kamsky Assignee: Ted Tuckman
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Sprint: QO 2021-11-01
Participants:
Case:

 Description   

Since user cannot insert a document without "_id" value, it's not very user friendly to start failing every single document when they add additionalProperties:false without enumerating _id field explicitly properties (or having it covered in patternProperties).

It would be useful to log a warning when this scenario is detected.



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

Author:

{'name': 'Ted Tuckman', 'email': 'ted.tuckman@mongodb.com', 'username': 'TedTuckman'}

Message: SERVER-32160 Warn users of schemas that reject all documents
Branch: master
https://github.com/mongodb/mongo/commit/69deb146486f0faee3c7115b7a27643a02f0c2af

Comment by Asya Kamsky [ 26/Dec/17 ]

Changed title and description to request to log a warning when validator is such that no document with _id would be accepted.

Comment by Asya Kamsky [ 26/Dec/17 ]

Maybe this is more of an enhancement to UX - when document validator on a collection includes "additionalFields:false" and does not include "_id" in list of properties, we should return/log a warning. Could be a shell or Compass feature for returning a warning, but logging a warning (while not easy to see) might also help in eventual "debugging".

This will be less of an issue when SERVER-20547 is implemented.

Comment by David Storch [ 05/Dec/17 ]

This would be an odd departure from the JSON Schema specification. If we want better behavior for _id, I suggest that we achieve this by adding support for a custom keyword, rather than implicitly diverging from the specification for top-level schema definitions.

Comment by Kyle Suarez [ 05/Dec/17 ]

While designing the behavior of $jsonSchema, our approach was to stick as close to the official specification as possible. But I suppose that with the addition of the bsonType keyword, we've already made some significant changes to make JSON Schema work for MongoDB.

I'd be okay with this change as long as it were clearly documented, so I marked documentation changes as "Needed". This is probably the expected behavior from a casual user's point of view, anyway (one who is not used to using JSON Schema elsewhere).

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