JSON backward compatibility check for adding non-required fields
See original GitHub issueJSON backward compatibility check for adding non-required fields
Hello,
I am testing the JSON compatibility for adding non-required fields. There are multiple cases when adding fields in JSON Schema that seem incorrect. This cases should be work without “additionalItems”: false but when I remove it the check compatibility update is failed.
For example,
- Should be backward compatible without “additionalItems”: false
"original": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "array",
"items": [
{
"type": "string"
},
{
"type": "number"
}
]
},
"updated": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "array",
"items": [
{
"type": "string"
},
{
"type": "number"
},
{
"type": "boolean"
}
]
}
- Should be backward compatible without “additionalItems”: false
"original": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"postal_code": {
"type": "number"
},
"street": {
"type": "string"
}
}
},
"updated": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"postal_code": {
"type": "number"
},
"street": {
"type": "string"
},
"country": {
"type": "string"
}
},
"additionalProperties": {
"type": "string"
}
}
- Also the case should be failed because in updated schema should be only “type”: “string” properties
"original": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"postal_code": {
"type": "number"
},
"street": {
"type": "string"
}
},
"additionalProperties": false
},
"updated": {
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"postal_code": {
"type": "number"
},
"street": {
"type": "string"
},
"country": {
"type": "string"
}
},
"additionalProperties": {
"type": "string"
}
}
What do you think about it?
Issue Analytics
- State:
- Created a year ago
- Comments:11 (6 by maintainers)
Top Results From Across the Web
BACKWARD compatibility fails for JSON schema when adding ...
If I set the latest schema compatibility to BACKWARD and add a new field to my new evolved schema it should test OK...
Read more >Testing two versions of json-schema for backwards compatibility
I have a repository that contains versioned json-schemas so for each type of schema I could have several revisions: v1, v2, v3 etc....
Read more >Understanding JSON Schema Compatibility - Robert Yokota
When adding a property in a backward compatible manner, the schema of the property being added must be backward compatible with the schema...
Read more >How to avoid breaking changes in your REST API with OpenAPI
Stating that your API is backward compatible gives your API consumers some confidence. It is not even that hard to achieve backward ...
Read more >Backward Compatibility - The Fast and Flexible Headless CMS
This page explains how to determine if a distribution is backward compatible or not. What is Backward Compatibility? In the context of deployment...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for the discussion. This happens exactly because
additionalProperties: true
, but would be ok ifadditionalProperties: false
.It will be good feature I think. In my case I want to update json schemas backward compatible and clients forget to add
additionalProperties: false
to schema from the start. So if they want to update it, they need to create new one because it is more strict and not possible to addadditionalProperties: false
or new field. That’s why I raise this question.