On Thu, May 9, 2013 at 12:56 PM, Dannon Baker <dannon.baker@gmail.com> wrote:
This isn't an issue with postgresql or mysql; they don't use a temporary table for table alterations.
Oh good :)
Can you open up the sqlite database if you still have it and see what the contents of the migrate_tmp table were? They'll be a copy of a prior migrated table, I'm just curious what from -- it should have been cleaned up previously in the event of successful migrations.
It looks like whatever was there has been lost (which doesn't really worry me on this machine - it is a test setup only): $ sqlite3 database/universe.sqlite SQLite version 3.6.20 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> select * from migrate_tmp; Error: no such table: migrate_tmp
My hunch is that previously various scripts threw a lot of errors for mysql and so this table wasn't automatically cleaned up after after the execution of one of those migration scripts, but the old version of sqlalchemy-migrate didn't care if it existed or not and would overwrite it, while the new version is more reticent to delete the table (which is probably more reasonable, should you need to recover data after an unsuccessful migration).
That makes sense.
In any event, to fix it, you'll want to make sure that the contents of that migrate_tmp table aren't something you want and drop it, downgrade to 114, then upgrade to 115 again. If I can recreate this I'll work on a more reasonable solution.
One idea might be to name the migration_tmp tables using the schema revision to avoid clashes, e.g. migration_115_tmp in this case? Peter