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
Instead of just storing the event contents as three anonymous dicts we should use pydantic to allow proper typed instance attributes. I tried it out with the ArtC event in magnusbaeck@59136e4. Writing these classes by hand is rather boring so we should explore using github.com/koxudaxi/datamodel-code-generator to generate the code.
Motivation
Typed classes would enable linters and IDEs to help out when writing code that accesses events.
Exemplification
I'd expect any piece of code that creates events would be easier to write. Reasonable people may disagree, but pydantic-based classes can be initialized from a dict so you could continue working with dicts if you prefer (but the syntax would be slightly different so it would break backwards compatibility).
Benefits
See Motivation, above.
Possible Drawbacks
It's not clear how we should deal with different versions of the events. When producing events we can probably just use the latest known version, but what do we do when deserializing events of old versions? They might not be acceptable to the current version of the schema (which is what the pydantic model would contain). Should we version the event classes too, when necessary?
The text was updated successfully, but these errors were encountered:
Description
Instead of just storing the event contents as three anonymous dicts we should use pydantic to allow proper typed instance attributes. I tried it out with the ArtC event in magnusbaeck@59136e4. Writing these classes by hand is rather boring so we should explore using github.com/koxudaxi/datamodel-code-generator to generate the code.
Motivation
Typed classes would enable linters and IDEs to help out when writing code that accesses events.
Exemplification
I'd expect any piece of code that creates events would be easier to write. Reasonable people may disagree, but pydantic-based classes can be initialized from a dict so you could continue working with dicts if you prefer (but the syntax would be slightly different so it would break backwards compatibility).
Benefits
See Motivation, above.
Possible Drawbacks
It's not clear how we should deal with different versions of the events. When producing events we can probably just use the latest known version, but what do we do when deserializing events of old versions? They might not be acceptable to the current version of the schema (which is what the pydantic model would contain). Should we version the event classes too, when necessary?
The text was updated successfully, but these errors were encountered: