-
Notifications
You must be signed in to change notification settings - Fork 45
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
Design: consider version fallback #473
Comments
What's the use case for falling back to the earlier schema? If |
This is a brief of the use case by @architgoyal1: In the following case it seems a reboot of Stream Enrich is needed:
(1-0-1 could be 1-1-0 or 2-0-0) Without a reboot to Stream Enrich, the events in steps 3 and 5 would all fail validation, rather than being validated against schema 1-0-0 (See this issue #473) |
Isn't that problem just solved by the default expiry of the caching of missing schemas? |
The caching issue -- yes; but people sending events before deploying schemas is rather common. On the other hand, with Event Recovery 0.1.0 now out, those failures should be easier to recover from... |
Right now if client requests
1-0-1
, but it does not exist, entity just fails with "schema not found". @dilyand is wondering if instead it can fallback to1-0-0
.A counterargument: client defined
1-0-0
schema with some keys. Then sends an event with1-0-1
unkownbar
key of length 30, it falls back to1-0-0
. Then client uploads1-0-1
withbar
maxLength
10. We have a falsely valid entity.A counterargument to conterargument: if
1-0-0
validates this unknownbar
it must haveadditionalProperties: true
. In that case next schema with definedbar
should not be an ADDITION.The text was updated successfully, but these errors were encountered: