Repository navigation
How to handle local development (pre-migration)? #283
Description
When collaborating on a project, there needs to be a proper way to handle "temporary" migrations. I use the system of calling the migrations on my feature branch new-001-whatever.sql, so I can go through and number them properly when merging the PR, but can this be automated by the migrate command?
Something I've noticed other developers doing is creating the change locally in their database, then pasting the generated DDL code into a new migration, but when it comes to running gt migrate, there's then a failure because their local database already has the tables created...
Something to think about for a rainy day...
Activity
g105b commentedon Mar 22, 2026
Assume there are already
234migrations. The problem is while you're working on your feature branch, another developer can increase the migrations to235. If you started your migrations at235, there would be a conflict when you merged your branch. The solution is to create your new migrations sequenced from001, but prefixed withdev.query/_migration/dev-001-add-index.sqlquery/_migration/dev-002-customer-foreign-key.sqlThese will be applied to your database when you do
gt migrate, but when it comes to merging, you can performgt migrate --mergeto put them into the correct order. There might need to be some work avoiding clashes in the _migration table, but that sounds a lot simpler once they've already been run.g105b commentedon Apr 1, 2026
It might be a bit cleaner to have a
devdirectory within the_migrationparent directory.g105b commentedon Apr 1, 2026
The current system assumes one global, monotonically increasing migration sequence in
query/_migration. That works for a solo workflow, but breaks down when multiple feature branches each add migrations independently. Two developers can both create0007-...sql, and by the time one branch is merged, the other branch’s migration numbers are no longer valid. The result is PR churn and a risk of editing already-run migration files just to renumber them.The proposed solution is to introduce a
query/_migration/devdirectory which separates the stable, merged migrations withinquery/_migrationand the branch-local disposable migrations inquery/_migration/dev.Plan
query/_migration/devalongside the existing main migration path logic inExecuteCommand._migration_devto avoid messing up existing behaviour.DevMigratorwhich can reuse most of theMigratorclass, but with differing responsibilities: load new dev migration files, sorted by local sequence, and only running ones not recorded in the local _migration_dev file. Hash and identity should be ran after success.gt migratearguemnts:gt migrate --devwill apply all migrations in the main sequence, as well as the new ones in the dev directory.gt migrate --dev-mergewill take the current dev files and move them to the correct location on disk, along with moving the migration records in the database to the correct location.Unsorted thoughts
gt migrate --reset-devmakes sense. But what about things that had already been migrated? Do we need a way to store a snapshot before migrating, so we can rewind to that point?feature: implement DevMigrator
pixeldrift64 commentedon May 5, 2026
Will test this on a project when I have migrations to run
feature: implement DevMigrator closes #283 (#394)