Repository navigation
Migrations system: sqlite_utils.Migrations and sqlite-utils migrate command, ported from sqlite-migrate #752
Description
The https://github.com/simonw/sqlite-migrate library is still in beta but it's been proving itself for 3 years now. It's time it became a feature of sqlite-utils.
Activity
simonw commentedon Jun 20, 2026
My plan is to do a
sqlite-migraterelease that pins to<4, then publish sqlite-utils 4 with this new feature and straight after to asqlite-migraterelease than pins>=4and imports stuff from the new home.simonw commentedon Jun 20, 2026
Actually since there are
sqlite-utils 4.xalphas out there that do NOT have the migrate functionality in I think the correct pin forsqlite-migrateis:Pin to sqlite-utils<4
sqlite-utils!=4.0,<4.0.post0
[-]Merge sqlite-migrate into sqlite-utils[/-][+]Migrations system: `sqlite_utils.Migrations` and `sqlite-utils migrate` command, ported from `sqlite-migrate`[/+]Final edits to migrations documentation, refs #752
simonw commentedon Jun 21, 2026
Spotted a design flaw in this command, inherited from
sqlite-migrate:That
path/to/migrations.pyfile might actually contain more than one migration set. If they both have a migration calledadd_weightboth will stop there. This is a little confusing.I want to maintain backwards compatibility with
sqlite-migrateso I think I'll solve that like this:You can optionally namespace the stop before indicators -
migration_set:name_of_migration- and you can pass more than one--stop-before.The old form still works - if you don't include a
:we match on name and ignore the migration set.Better --stop-before
Better --stop-before
New migrations system, ported from sqlite-migrate (#754)
Release 4.0rc1
Release 4.0rc1