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
Recently we had a case where a user had gotten diverging migrations in production and staging databases.
They got there by:
creating a migration in VCS and successfully applying it to staging database,
trying to apply it to production database, where they failed,
replacing it with a fixed migration and successfully applying it to the production database.
The schemas of the two databases might be exactly the same, but last applied migration has a different hash, so going forward, new migrations cannot be applied to both databases.
EdgeDB has mechanisms for dealing with such scenarios (migration rewrites), but CLI uses them only when squashing migrations. We should use migration rewrites for this use case as well.
I'd suggest the following fixup path:
first, user needs to decide which migration history should be considered the "source of truth" (in the case above, that would probably be the production database),
edgedb-cli migration extract --force -I prod to override migrations in dbschema/migrations (this already exists),
now, create "fixup migrations" for each of the other databases that we want to move to the "source of truth" schema:
edgedb-cli migration extract --rewrite to create a "fixup migration" that would, when applied:
a) migrate the database to the "source of truth" schema,
b) apply a migration rewrite
The text was updated successfully, but these errors were encountered:
Recently we had a case where a user had gotten diverging migrations in production and staging databases.
They got there by:
The schemas of the two databases might be exactly the same, but last applied migration has a different hash, so going forward, new migrations cannot be applied to both databases.
EdgeDB has mechanisms for dealing with such scenarios (migration rewrites), but CLI uses them only when squashing migrations. We should use migration rewrites for this use case as well.
I'd suggest the following fixup path:
edgedb-cli migration extract --force -I prod
to override migrations indbschema/migrations
(this already exists),edgedb-cli migration extract --rewrite
to create a "fixup migration" that would, when applied:a) migrate the database to the "source of truth" schema,
b) apply a migration rewrite
The text was updated successfully, but these errors were encountered: