[SERVER-30723] Add a query knob that controls whether JSON Schema ignores or errors on unknown keywords Created: 17/Aug/17 Updated: 30/Oct/23 Resolved: 12/Sep/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Nicholas Zolnierz | Assignee: | Nicholas Zolnierz |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Query 2017-10-02 |
| Participants: |
| Description |
|
According to the JSON Schema Core Spec ยง5.6:
|
| Comments |
| Comment by Ramon Fernandez Marina [ 12/Sep/17 ] |
|
Author: {'username': u'nzolnierzmdb', 'name': u'Nick Zolnierz', 'email': u'nicholas.zolnierz@mongodb.com'}Message: |
| Comment by Asya Kamsky [ 23/Aug/17 ] |
|
I think it's more consistent with direction we are trying to move to not to silently ignore unknown words/options/commands. However I can see some users wanting to be able to have us ignore keywords which are not part of the known set. |
| Comment by David Storch [ 22/Aug/17 ] |
|
asya, are you saying that the default behavior is to reject unknown keywords, but that there will be something like internalQueryAcceptUnknownJSONSchemaKeywords which can be toggled to true? If we care about supporting non-standard keywords, why wouldn't we take the spec's advice and just always ignore them? |
| Comment by Kyle Suarez [ 21/Aug/17 ] |
|
Throwing this back into Needs Triage so we can consider the query knob approach. |
| Comment by Asya Kamsky [ 21/Aug/17 ] |
|
Given our users already have jsonSchema documents I would prefer we provide an option (internal query knob?) that would allow ignoring rather than throwing an error on unrecognized keywords. |
| Comment by Asya Kamsky [ 21/Aug/17 ] |
|
We do have users/customers who current use JSON schema documents on the application side to make sure the format of the documents is "correct". Looking at the files I have I need to know if we are talking about failing on keywords that are completely non-standard (their own extension) and ignoring existing "real" keywords that we don't implement? |
| Comment by David Storch [ 21/Aug/17 ] |
|
There are good arguments in both directions. In order for us to decide what behavior we want, I think we need to know how many users we expect to have pre-existing schemas with non-standard keywords. asya would you be able to research this for us? Is it important for non-standard schemas to be accepted by MongoDB's implementation? |
| Comment by Kyle Suarez [ 18/Aug/17 ] |
|
david.storch, there's an argument to ignoring unrecognized keywords, since products like Hackolade use many non-standard keywords, and ignoring these would allow you to do a drop-in replacement. However, I think overall it's a better user experience to error. I'd rather get an explicit message telling me that this keyword isn't recognized, rather than silently accepting it and not doing anything, confusing the user if they expected something to happen. |
| Comment by David Storch [ 18/Aug/17 ] |
|
kyle.suarez nicholas.zolnierz, I feel like this is unfriendly behavior and not consistent with our preference for other components of MongoDB. Typically we try to fail user queries that specify an option or operator which we do not know about. Since the spec uses the qualifier "SHOULD", I think we can keep the current behavior and still be spec compliant. We should definitely ignore valid JSON Schema keywords which our implementation does not support, but I think that any keyword which is not mentioned whatsoever in draft 4 should result in an error. Do you agree? |