I was able to reproduce the problem (ironically, on the cloud) and it seems to be an issue with how postgres drops tables: if there are foreign key dependencies between tables, it does not drop them. Some sort of a workaround that's custom to postgres will be needed but since it's not messing things up, it may be a while...


On Wed, Jun 30, 2010 at 3:42 PM, Assaf Gordon <gordon@cshl.edu> wrote:
It's postgreSQL .

My database has been upgraded (and never re-created from scratch) since may 2008, so it's quite possible it has some "ghosts" in it.
I have never used any Cloud related features, so it's not a problem.
I'm not sure which ones are the "cloud tables", but I can send you the schema if needed.

Enis Afgan wrote, On 06/30/2010 07:50 AM:
> Hi,
> What database is this with? I've tried this migration script with
> Postgres and SQLite but neither time did I see the mentioned error. I
> assume the cloud tables are still there?
>
> Enis
>
> On Tue, Jun 29, 2010 at 4:57 PM, Assaf Gordon <gordon@cshl.edu
> <mailto:gordon@cshl.edu>> wrote:
>
>     Hi,
>
>     After pulling the latest changes and upgrading the DB, I get the
>     following error:
>
>     ===
>     45 -> 46...
>     Migration script to create tables for handling post-job actions.
>     done
>     46 -> 47...
>     Add a user_id column to the job table.
>     Updating user_id column in job table for  76013  rows...
>     Updated the user_id column for  75646  rows in the job table.
>     367  rows have no user_id since the value was NULL in the
>     galaxy_session table.
>     done
>     47 -> 48...
>     Add a state column to the history_dataset_association and
>     library_dataset_dataset_association table.
>     done
>     48 -> 49...
>     Migration script to add the api_keys table.
>     done
>     49 -> 50...
>     ========================================
>     This script drops tables that were associated with the old Galaxy
>     Cloud functionality.
>     ========================================
>     DEBUG:0050_drop_cloud_tables:Dropping cloud tables failed:
>     (InternalError) cannot drop table cloud_provider because other
>     objects depend on it
>     HINT:  Use DROP ... CASCADE to drop the dependent objects too.
>      '\nDROP TABLE cloud_provider' {}
>     done
>     ====
>
>     However, Galaxy runs fine afterwards.
>
>     -gordon
>     _______________________________________________
>     galaxy-dev mailing list
>     galaxy-dev@lists.bx.psu.edu <mailto:galaxy-dev@lists.bx.psu.edu>
>     http://lists.bx.psu.edu/listinfo/galaxy-dev
>
>