db_setup creates and migrates a mem migration of None -> "current".
If an application then uses its own migrations, either embedded or from disk, the migration will fail on postgres because the objects already exist in the database.
testall_no_migrate can be used as a workaround, but it is nice for most tests to be using the "auto-migrate" testall so the test can assume it doesnt need to migrate, and it doesnt matter if the application does a migrate, which would be a no-op.
The fix is for db_setup to copy any existing disk migrations into a MemMigrations, and then add another MemMigration for "current" if there are pending changes. This shouldnt slow down the tests here too much, as butane/ tests dont have any disk migrations.
I've got a branch that does this, but then I got distracted with other things and created a few more important PRs which will conflict with this. So this is mostly a reminder to self.
db_setupcreates and migrates a mem migration of None -> "current".If an application then uses its own migrations, either embedded or from disk, the migration will fail on postgres because the objects already exist in the database.
testall_no_migratecan be used as a workaround, but it is nice for most tests to be using the "auto-migrate"testallso the test can assume it doesnt need to migrate, and it doesnt matter if the application does a migrate, which would be a no-op.The fix is for
db_setupto copy any existing disk migrations into aMemMigrations, and then add anotherMemMigrationfor "current" if there are pending changes. This shouldnt slow down the tests here too much, asbutane/tests dont have any disk migrations.I've got a branch that does this, but then I got distracted with other things and created a few more important PRs which will conflict with this. So this is mostly a reminder to self.