On Thu, May 9, 2013 at 12:56 PM, Dannon Baker <dannon.ba...@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 ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
