-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Schema evolution #5
Comments
Here's my last significant comment on that issue: For transforming JSON representations from one version to another, I would look at JSON Patch. It can express such concepts as "rename field X to Y", as well as adding and removing fields, and even limited conditionals by testing field values. I guess the question then would be whether and how to integrate such a usage of JSON Patch into JSON Schema. There's really no notion of versioning built into JSON Schema / Hyper-Schema. Each schema exists on its own. A system designer can indicate that a set of schemas form a sequence of versions, but that's an entirely external concept. |
I would like to comment on this and closed issue #285, as well as to check on status of this issue. I feel like conversation in #285 went an unexpected direction - to XSLT and transformation, that is unlikely a purpose of field
This is especially important using messaging patterns integrating multiple domains. Additionally, there is a scenario replaying old events; producer might not even support an event (schema) any longer, but consumer may want to replay it after domain has evolved. I would describe the functionality as "Ingest data AS", instead of just delivering evolutionary changes as JSON Patch does. Currently JSON Schema allows to handle deletes and field addition as perfectly pointed out in #285, but unfortunately does not provide a clean way to rename a field. Adding an @handrews, can you please re-evaluate this option considering possible inclusion? It will help many people to solve schema evolution problems as Avro was solving it for years. |
Re-opening this as it was not being tracked anywhere else- the issue in the other repo was closed. |
FWIW Wikimedia is doing this manually with some tooling: https://github.com/wikimedia/jsonschema-tools |
This was originally filed by @cavanaug as json-schema-org/json-schema-spec#285, where it originally referenced Avro's "aliases" as a starting point. This is probably the most concise explanation from @cavanaug:
@cavanaug also said:
This may fit as part of an "API Documentation" vocabulary, although whether that is really web APIs in the specific sense or just "system where you interact with stuff that changes over time" is an open question. I take a pretty broad view of "API" so any sort of data processing system could fit (maybe the vocabulary needs a different name- we're still sorting out how and where this sort of thing should live and relate to existing vocabularies).
The text was updated successfully, but these errors were encountered: