Migration production safety questions (concurrency, rollbacks, out-of-order application)
Hi, Community!
New to Drizzle, investigating it as a candidate for next larger quite heavy production project, decided to test something new instead of battle-tested
DB is
So have few questions which come from experience I could spend time indo digging into code, but decided to ask first if someone is aware of behavioural details here.
Usually when you number of pods, you may have in theory multiple migration invocations.
As I've checked SQL executed by Drizzle, it searches for last applied transaction, then applies next one in transaction together with inserting. I see no kind of blocking (e.g. exclusive lock on migration table) to ensure transaction can be applied only once.
Did I get it right, or there's some mechanics to protect from concurrent migrations?
Case for reliable prod - you do migrations, you roll code, you see problem, you rollback making your old code working on new already migrated DB schema.
In that case
That's comes from development flow:
- You're writing develop code and prepare migration
- You've deployed it to server, did some tests
- You do rebase, and now there's new migration file
- On deploying to test server turns out one migration got skipped
Will Drizzle detect that kind of a problem on it's own? (making it short to match limit )
New to Drizzle, investigating it as a candidate for next larger quite heavy production project, decided to test something new instead of battle-tested
knexPostgreSQLSo have few questions which come from experience
I could spend time indo digging into code, but decided to ask first if someone is aware of behavioural details here.1. Concurrent migration application
Usually when you number of pods, you may have in theory multiple migration invocations.
As I've checked SQL executed by Drizzle, it searches for last applied transaction, then applies next one in transaction together with inserting. I see no kind of blocking (e.g. exclusive lock on migration table) to ensure transaction can be applied only once.
__drizzle_migrationsDid I get it right, or there's some mechanics to protect from concurrent migrations?
2. Rollback migration code (node SQL migration itself)
Case for reliable prod - you do migrations, you roll code, you see problem, you rollback making your old code working on new already migrated DB schema.
In that case
migration3. Prevent out-of-order migration
That's comes from development flow:
- You're writing develop code and prepare migration
- You've deployed it to server, did some tests
- You do rebase, and now there's new migration file
- On deploying to test server turns out one migration got skipped
Will Drizzle detect that kind of a problem on it's own? (making it short to match limit
)