You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a feature request for a function that identifies whether two schemas are "compatible," and if not, potentially provides information about any discovered incompatibilities.
Consider use cases in which ISL defines a contract, and another ISL defines a portion of the contract actually consumed by a consumer (e.g., APIs, data publisher/consumer contracts, etc.). Before evolving a contract in a backwards incompatible way, it would be helpful to know which consumers (if any) would be affected by the breaking change.
A collapsed, canonical form of each schema with all imports inlined is likely a helpful starting point for such a compatibility check.
This is a non-trivial feature request, and any such feature would need to be precise about what "compatible" means, and clear about its limitations. The following is a non-exhaustive list of complications that come to mind:
determining compatibility between two regex constraints is challenging at best
logic constraints present interesting challenges, especially not
some changes identified as incompatible may or may not actually break consumers (e.g., allowing a string to be longer), but knowing this for certain requires understanding the code that will process the data
...
An initial approach to this (and one that probably covers a large percentage of use cases while reducing complexity) would likely:
focus on a structural comparison of schemas (are they of the same type? do structs have a compatible set of fields? etc.)
avoid any comparison logic based on value constraints (e.g., regex, valid_values, length, precision)
the not constraint is a curious one, and might be supported if the context is within a known, "closed" universe of types (in which case not can be rewritten as an any_of constraint)
The text was updated successfully, but these errors were encountered:
This is a feature request for a function that identifies whether two schemas are "compatible," and if not, potentially provides information about any discovered incompatibilities.
Consider use cases in which ISL defines a contract, and another ISL defines a portion of the contract actually consumed by a consumer (e.g., APIs, data publisher/consumer contracts, etc.). Before evolving a contract in a backwards incompatible way, it would be helpful to know which consumers (if any) would be affected by the breaking change.
A collapsed, canonical form of each schema with all imports inlined is likely a helpful starting point for such a compatibility check.
This is a non-trivial feature request, and any such feature would need to be precise about what "compatible" means, and clear about its limitations. The following is a non-exhaustive list of complications that come to mind:
not
An initial approach to this (and one that probably covers a large percentage of use cases while reducing complexity) would likely:
not
constraint is a curious one, and might be supported if the context is within a known, "closed" universe of types (in which casenot
can be rewritten as anany_of
constraint)The text was updated successfully, but these errors were encountered: