Skip to content

The fork's Google Drive migration is idempotent, so a fresh database that also gets upstream's copy still migrates - #30

Merged
gedaiu merged 1 commit into
re-devfrom
fix/google-drive-migration-is-idempotent
Oct 23, 2026
Merged

gedaiu merged 1 commit into
re-devfrom
fix/google-drive-migration-is-idempotent

Conversation

@gedaiu

@gedaiu gedaiu commented Oct 23, 2026

Copy link
Copy Markdown

#29 renamed the migration to 9006 but committed the old content: plain CREATE TABLE, no fork header. That runs fine today, but once the upstream sync brings deeplethe#1386's 0120 copy, a fresh database runs 0120 first and then fails on 9006. This commits the IF NOT EXISTS version with the header.

It must merge before any release is deployed: once 9006 has run in production its checksum is fixed and the file can't change. v0.1.0-re.18 carries the old file, so it should not be deployed.

Checked on fresh databases, rebuilding each time (sqlx::migrate! embeds the files at compile time): 9006 alone, an existing database that later gets 0120, and a fresh one with both all migrate cleanly.

…that also gets upstream's copy still migrates

Signed-off-by: Bogdan Szabo <bogdan@re-cinq.com>
@gedaiu
gedaiu merged commit 52664f2 into re-dev Oct 23, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant