fix(migrations): stop migrator.up() from churning a snapshot that matches the DB#7804
Merged
Merged
Conversation
…ches the DB `migration:create` writes `.snapshot-<db>.json` from entity metadata, while `migration:up`/`migration:down` rewrite it from DB introspection. Even when the migrated database still matches the snapshot, the two serializations diverge in cosmetic-only ways the comparator already treats as equal (default casing, generated-/where-expression reformatting, native-enum mapped type, index method, check definition format), so every `up()` produced a noisy snapshot diff. Skip the rewrite when the introspected schema does not differ from the on-disk snapshot in any way the comparator turns into SQL — the file then stays exactly as authored by `migration:create`. A real schema change (or a stale snapshot) still rewrites it as before. Refs #7798
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #7804 +/- ##
========================================
Coverage 99.64% 99.64%
========================================
Files 285 285
Lines 29664 29671 +7
Branches 8119 8291 +172
========================================
+ Hits 29559 29566 +7
Misses 98 98
Partials 7 7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #7803 (now merged) for the Postgres side of #7798.
migration:createwrites.snapshot-<db>.jsonfrom entity metadata, whilemigration:up/migration:downrewrite it from DB introspection. Even when the migrated database still matches the snapshot, the two serializations diverge in cosmetic-only ways theSchemaComparatoralready treats as equal:current_timestamp→CURRENT_TIMESTAMP(default casing)(coalesce(...) ...) STORED→(COALESCE(...) ...) stored(generated-expr reformatting)whereclauses rewrapped with explicit casts (status = 'PENDING'→(status)::text = 'PENDING'::text)mappedType, indexginmethod, checkdefinitionformatSo every
migrator.up()produced a noisygit diffon the snapshot even with no real schema change (the reported symptom). These can't all be normalized byte-for-byte intoJSON()— Postgres rewrites the stored expressions unpredictably.Instead, skip the rewrite when the introspected schema doesn't differ from the on-disk snapshot in any way the comparator turns into SQL. The file then stays exactly as authored by
migration:create. A real schema change (or a stale snapshot) still rewrites it as before — the existing sqlite up/down snapshot test is updated to assert this no-churn guarantee.Closes #7798