On Tue, Feb 18, 2014 at 1:40 PM, Dannon Baker dannon.baker@gmail.com wrote:

On Tue, Feb 18, 2014 at 8:30 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

...

This fixed the history_dataset_association.extended_metadata_id error - so is the most likely explanation a failed schema update? Might a stale migration_tmp table have been to blame?

Yes, I've seen this before when I've killed (or otherwise crashed) a migration in process; migrate_tmp doesn't get automatically cleaned up -- and, to allow for recovery, probably shouldn't.

Tricky one - perhaps what would be best is to abort with an explicit error if there is already a (stale) migrate_tmp table present?

Any idea what may have caused it in your case?For a development database I've most commonly just deleted the migrate_tmp table manually and rerun the migration.

I don't know what went wrong here - it could have happened a while back, with the stale migrate_tmp table waiting harmlessly until I ran a schema update today.

It's worth noting that *only* sqlite can have this problem, due to the way migrations work.

I thought that might be the case.

Thanks,

Peter

Hey Pieter, sure. The sqlite database is in sqlite3 format, so you'll need to use 'sqlite3 database/universe.sqlite' to access it.

The following should work:

sqlite3 database/universe.sqlite '.dump migrate_tmp' > temporary_backup.sql sqlite3 database/universe.sqlite 'drop table migrate_tmp;'

And, once that's done, verify that everything works as expected and that whatever table is in temporary_backup.sql actually did get migrated.

-Dannon

On Tue, Apr 22, 2014 at 8:41 AM, Lukasse, Pieter pieter.lukasse@wur.nlwrote:

Hi Dannon,

I’m facing the same problem now. Could you help me with the steps to delete the migrate_tmp table manually? I’m trying to use sqlite from command line but get the following error:

Unable to open database "universe.sqlite": file is encrypted or is not a database

Thanks and regards,

Pieter.

*From:* galaxy-dev-bounces@lists.bx.psu.edu [mailto: galaxy-dev-bounces@lists.bx.psu.edu] *On Behalf Of *Dannon Baker *Sent:* dinsdag 18 februari 2014 14:40 *To:* Peter Cock *Cc:* Galaxy Dev *Subject:* Re: [galaxy-dev] (OperationalError) no such column: history_dataset_association.extended_metadata_id

On Tue, Feb 18, 2014 at 8:30 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

This fixed the history_dataset_association.extended_metadata_id error - so is the most likely explanation a failed schema update? Might a stale migration_tmp table have been to blame?

Yes, I've seen this before when I've killed (or otherwise crashed) a migration in process; migrate_tmp doesn't get automatically cleaned up -- and, to allow for recovery, probably shouldn't. Any idea what may have caused it in your case?For a development database I've most commonly just deleted the migrate_tmp table manually and rerun the migration. It's worth noting that *only* sqlite can have this problem, due to the way migrations work.

-Dannon

Ok, great, glad that worked for you. And, thanks for the heads up on the actual table name :)

-Dannon

On Tue, Apr 22, 2014 at 9:14 AM, Lukasse, Pieter pieter.lukasse@wur.nlwrote:

Hi Dannon,

Thanks, this helped.

Just for the record: I did find a small typo in my mail and in your script : should be migration_tmp instead of migrate_tmp ;)

Best regards,

Pieter.

*From:* Dannon Baker [mailto:dannon.baker@gmail.com] *Sent:* dinsdag 22 april 2014 14:59 *To:* Lukasse, Pieter *Cc:* Peter Cock; Galaxy Dev

*Subject:* Re: [galaxy-dev] (OperationalError) no such column: history_dataset_association.extended_metadata_id

Hey Pieter, sure. The sqlite database is in sqlite3 format, so you'll need to use 'sqlite3 database/universe.sqlite' to access it.

The following should work:

sqlite3 database/universe.sqlite '.dump migrate_tmp' > temporary_backup.sql

sqlite3 database/universe.sqlite 'drop table migrate_tmp;'

And, once that's done, verify that everything works as expected and that whatever table is in temporary_backup.sql actually did get migrated.

-Dannon

On Tue, Apr 22, 2014 at 8:41 AM, Lukasse, Pieter pieter.lukasse@wur.nl wrote:

Hi Dannon,

I’m facing the same problem now. Could you help me with the steps to delete the migrate_tmp table manually? I’m trying to use sqlite from command line but get the following error:

Unable to open database "universe.sqlite": file is encrypted or is not a database

Thanks and regards,

Pieter.

*From:* galaxy-dev-bounces@lists.bx.psu.edu [mailto: galaxy-dev-bounces@lists.bx.psu.edu] *On Behalf Of *Dannon Baker *Sent:* dinsdag 18 februari 2014 14:40 *To:* Peter Cock *Cc:* Galaxy Dev *Subject:* Re: [galaxy-dev] (OperationalError) no such column: history_dataset_association.extended_metadata_id

On Tue, Feb 18, 2014 at 8:30 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

This fixed the history_dataset_association.extended_metadata_id error - so is the most likely explanation a failed schema update? Might a stale migration_tmp table have been to blame?

Yes, I've seen this before when I've killed (or otherwise crashed) a migration in process; migrate_tmp doesn't get automatically cleaned up -- and, to allow for recovery, probably shouldn't. Any idea what may have caused it in your case?For a development database I've most commonly just deleted the migrate_tmp table manually and rerun the migration. It's worth noting that *only* sqlite can have this problem, due to the way migrations work.

-Dannon