question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

JSON backward compatibility check for adding non-required fields

See original GitHub issue

JSON 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,

  1. 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"
    }
  ]
}
  1. 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"
        }
      }

  1. 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:closed
  • Created a year ago
  • Comments:11 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
jsenkocommented, Nov 15, 2022

Thanks for the discussion. This happens exactly because additionalProperties: true, but would be ok if additionalProperties: false.

0reactions
arturkandurcommented, Nov 16, 2022

But there is a possibility we will add a less strict mode in the future if it is useful.

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 add additionalProperties: false or new field. That’s why I raise this question.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found