Skip to content

v2.0.1 — migration data-loss fix

Choose a tag to compare

View all tags
@gavdevs gavdevs released this 12 Jul 23:40
· 7 commits to main since this release
Immutable release. Only release title and notes can be modified.
v2.0.1
93705a4

Patch release fixing data loss during the v2.0.0 database migration. If you upgraded to v2.0.0 with existing data, your plans survived but their meals and grocery items were deleted — restore your pre-upgrade ./data/ backup and start the container on this version instead. If you haven't upgraded yet, skip 2.0.0 and go straight to 2.0.1.

The bug

The migration runner executes each migration inside a transaction, where the PRAGMA foreign_keys=OFF embedded in the migration SQL is silently ignored. With foreign-key enforcement still active, v2.0.0's meal_plans table rebuild (DROP TABLE) fired ON DELETE CASCADE on meals and grocery_items, deleting every row. Fresh installs were unaffected.

The fix

Migrations now run with foreign-key enforcement disabled at the connection level (re-enabled afterwards), and a regression test walks real v1-model data through the actual migrator asserting meals and grocery items survive the week→plan conversion.

Upgrading

  • From pre-2.0 with data: back up ./data/, then docker compose pull && docker compose up -d. Weeks convert to plans exactly as described in the v2.0.0 notes — meals and grocery lists intact this time.
  • From 2.0.0 (migration already ran and ate your meals): stop the container, restore your pre-upgrade data/ backup over the current one, pull 2.0.1, start. The migration re-runs correctly against the restored data.
  • Fresh installs: nothing to do.
Assets 3
Loading