393 introduced a change to the data model, but AIP had no way to automatically update data written in a prior version of the data models
That wasn't a breaking change, but we'll probably have breaking changes which pydantic will cry about in the future
Proposed Changes
Each top-level model now has a version attribute (was model_version, but this was a protected name in pydantic...). These top levels are chosen so that each persisted-to-file JSON dict has version as a top level key.
A liftover method registry is created, so that each transition between versions is accounted for. Each transition method should take data on one version of the model, and export data valid on the next model. If the versions are multiple releases apart, this chain can include multiple methods
If there is no liftover required for a model, no update method is registered
In future, when the model version number changes, any liftover methods need to be created and tests added to prove function
Fixes
393 introduced a change to the data model, but AIP had no way to automatically update data written in a prior version of the data models
Proposed Changes
versionattribute (wasmodel_version, but this was a protected name in pydantic...). These top levels are chosen so that each persisted-to-file JSON dict has version as a top level key.Checklist