- Newest
- Most votes
- Most comments
Hi, thanks for reaching out!
Yeah, you're right that the code base you can obtain for a given schema version is specific to that version, and that the downloaded code base doesn't allow for specifying an alternate version of that schema when put to use.
Short of creating your own component, another approach would be to utilize multiple independent schemas for multiple schema variations of a particular event, and just maintain a single version of each of those independent schemas.
Hi there,
We have an API GetCodeBindingSource (https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname-language-language-source.html) that has a schemaVersion field that allows customers to select the code binding version they want. If you know which version of an event you want, you can use this API to get the relevant code binding.
The customer would need to build their custom solution for this though.
We have projects in our roadmap to better streamline this use case but at the moment the below is recommended.
-
For minor backwards compatible schema changes to the schema If the changes are of this type that would means in theory the newer schema version should actually be usable to deserialize old events too, and then the customer can do runtime checks on the deserialized object to evaluate which version it's coming from.
-
For non-backwards compatible breaking changes to the schema Our guidance today would be to actually use different Schemas, and different detail types. Then, they could use the detail type to pick the right schema and use the latest version of that schema.
Relevant content
- asked 3 years ago
- asked 9 months ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago