SaaS Flyway: timestamp-based migration naming to end version clashes#6871
Open
ConnorYoh wants to merge 1 commit into
Open
SaaS Flyway: timestamp-based migration naming to end version clashes#6871ConnorYoh wants to merge 1 commit into
ConnorYoh wants to merge 1 commit into
Conversation
SaaS Flyway: switch new migrations to timestamp-based naming The shared integer version counter (V25, V26, ...) collides whenever two branches are in flight: each grabs "the next number" and they clash on merge, breaking CI. Adopt UTC-timestamp naming (VYYYYMMDDHHMMSS__desc.sql) for new migrations so parallel branches never pick the same version. Enable spring.flyway.out-of-order so a just-merged migration whose timestamp predates one already applied is still run (merge order != version order under timestamps). Safe because the saas migrations are additive and idempotent. Existing V2..V26 files are intentionally left as-is: they are already applied and tracked by version in flyway_schema_history, so renaming would re-run them or fail checksums. Timestamps sort after the legacy integers, so both coexist. Convention documented in db/migration/saas/README.md. @
dosubot
Bot
added
size:M
stirlingbot
Bot
added
Documentation
Contributor
🚀 V2 Auto-Deployment Complete!Your V2 PR with embedded architecture has been deployed! 🔗 Direct Test URL (non-SSL) http://54.175.155.236:6871 🔐 Secure HTTPS URL: https://6871.ssl.stirlingpdf.cloud This deployment will be automatically cleaned up when the PR is closed. 🔄 Auto-deployed for approved V2 contributors. |
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
1 participant
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.
@
Problem
SaaS Flyway migrations (
app/saas/src/main/resources/db/migration/saas/) use a shared integer version counter — currently up toV26. Whenever two branches are in flight, each grabs "the next number" (both pickV27), so they collide the moment both merge: a duplicate version or a checksum failure that breaks CI. The gaps in the current sequence (noV7,V10,V18, …) are the fingerprint of this churn.Change (stage 1 of 2)
Adopt UTC-timestamp naming for new migrations:
26 < 20260703143012), so both schemes coexist and apply in order.spring.flyway.out-of-order=true— under timestamps, merge order no longer matches version order, so without it Flyway would reject a just-merged migration whose timestamp predates one already applied. Safe here because the saas migrations are additive and idempotent (IF NOT EXISTS).Deliberately not renaming
V2..V26They are already applied in deployed/dev environments and tracked by version in
flyway_schema_history; renaming would make Flyway re-run them or fail the checksum check. They stay as integers; only new migrations use timestamps.Files
application-saas.properties— addspring.flyway.out-of-order=true(+ rationale comment)db/migration/saas/README.md— document the conventionFollow-up (stage 2, later)
Missed-migration / schema-drift detection in CI (the pg_dump-diff-against-Supabase idea) is intentionally out of scope here and will be a separate PR.
@