assert compatible schema version in data

[michaelglass]

in order to not invalidate fixtures with a moving schema
set a "compatible schema version"
and have live fixtures roll back to that version before loading

[SamGerber-zz]

I'm not sure I understand this issue.

By, "schema version", you mean the schema of the database, or are you referring to some sort of YAML schema?

When you say, "roll back to that version", does that mean rolling back migrations and then reapplying them over the imported data, or just checking out the old schema using git, or something else completely?

[michaelglass]

I mean database schema.

I don't have a prescriptive approach but I think a reasonable approach is rolling back to said schema migration, importing live fixtures, then rolling forward.

E.g.
on export: save schema version somewhere.

On import: if import fails (or maybe always) roll back to the saved schema version. run import. roll forward.

[SamGerber-zz]

I can see how this approach would be really useful in the context of a Ms Teacher import as part of the seeding of a local db, but I wonder what it would mean in the context of an import into a production db (ie creation of a new demo teacher). Would it potentially rollback slow migrations and break the site for other users while the import was in progress?

Does it seems feasible to build tooling to migrate fixtures? Maybe like:
on export: save schema version somewhere.
on db migrate:

• create duplicate db from structure.sql
• import a list of fixtures
• migrate the duplicate db
• export the fixtures
• drop the duplicate db
• migrate the real db

I dunno. Maybe the short-term solution is:
on export: save schema version somewhere.
on build: try to import a list of fixtures. If they break, fail the build and provide a link to instructions to fix them.