[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: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | QO 2021-11-01 | ||||
| Participants: | |||||
| Case: | (copied to CRM) | ||||
| 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: |
| 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 |
| 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). |