Hi everybody I usually don't like people sending the same e-mail several times, so I apologize for just doing this, since nobody has replied to last week's email so far. Although, we do not encounter any problems at the moment, I fear we will run into problems at a later stage (ie at the next code update). This is our production server. Thank you very much for any help Regards, Hans On 04/16/2012 03:43 PM, Hans-Rudolf Hotz wrote:
Hi
We are in the process of migrating our Galaxy servers to the current "March 12, 2012" release ('6799:40f1816d6857').
We have encountered two issues, which I guess are related:
If I restart the server, I get:
galaxy.model.migrate.check INFO 2012-04-16 09:24:50,391 At database version 93 galaxy.tool_shed.migrate.check DEBUG 2012-04-16 09:24:50,407 MySQL_python egg successfully loaded for mysql dialect Traceback (most recent call last): File "/****/galaxy_dist/lib/galaxy/web/buildapp.py", line 82, in app_factory app = UniverseApplication( global_conf = global_conf, **kwargs ) File "/****/galaxy_dist/lib/galaxy/app.py", line 37, in __init__ verify_tools( self, db_url, kwargs.get( 'global_conf', {} ).get( '__file__', None ), self.config.database_engine_options ) File "/****/galaxy_dist/lib/galaxy/tool_shed/migrate/check.py", line 42, in verify_tools db_schema = schema.ControlledSchema( engine, migrate_repository ) File "/****/galaxy_dist/eggs/sqlalchemy_migrate-0.5.4-py2.6.egg/migrate/versioning/schema.py", line 24, in __init__ self._load() File "/****/galaxy_dist/eggs/sqlalchemy_migrate-0.5.4-py2.6.egg/migrate/versioning/schema.py", line 42, in _load data = list(result)[0] IndexError: list index out of range
I can 'temporary' fix this by commenting-out line 36 and 37 in ~/lib/galaxy/app.py
36# from galaxy.tool_shed.migrate.check import verify_tools 37# verify_tools( self, db_url, kwargs.get( 'global_conf', {} ).get( '__file__', None ), self.config.database_engine_options )
...well, I don't like this fix, and I wonder if there is a better one?
I have a suspicion, that this is related to problems I encountered during the database schema upgrade to version 93 for our MySQL database:
at step "90to91" and "91to92" I get the following:
90 -> 91...
Migration script to create the tool_version and tool_version_association tables and drop the tool_id_guid_map table.
0091_add_tool_version_tables DEBUG 2012-04-16 08:55:49,719 Creating tool_version table failed: (OperationalError) (1050, "Table 'tool_version' already exists") u'\nCREATE TABLE tool_version (\n\tid INTEGER NOT NULL AUTO_INCREMENT, \n\tcreate_time DATETIME, \n\tupdate_time DATETIME, \n\ttool_id VARCHAR(255), \n\ttool_shed_repository_id INTEGER, \n\tPRIMARY KEY (id), \n\t FOREIGN KEY(tool_shed_repository_id) REFERENCES tool_shed_repository (id)\n)\n\n' () 0091_add_tool_version_tables DEBUG 2012-04-16 08:55:49,719 Creating tool_version table failed: (OperationalError) (1050, "Table 'tool_version' already exists") u'\nCREATE TABLE tool_version (\n\tid INTEGER NOT NULL AUTO_INCREMENT, \n\tcreate_time DATETIME, \n\tupdate_time DATETIME, \n\ttool_id VARCHAR(255), \n\ttool_shed_repository_id INTEGER, \n\tPRIMARY KEY (id), \n\t FOREIGN KEY(tool_shed_repository_id) REFERENCES tool_shed_repository (id)\n)\n\n' () 0091_add_tool_version_tables DEBUG 2012-04-16 08:55:49,720 Creating tool_version_association table failed: (OperationalError) (1050, "Table 'tool_version_association' already exists") u'\nCREATE TABLE tool_version_association (\n\tid INTEGER NOT NULL AUTO_INCREMENT, \n\ttool_id INTEGER NOT NULL, \n\tparent_id INTEGER NOT NULL, \n\tPRIMARY KEY (id), \n\t FOREIGN KEY(tool_id) REFERENCES tool_version (id), \n\t FOREIGN KEY(parent_id) REFERENCES tool_version (id)\n)\n\n' () 0091_add_tool_version_tables DEBUG 2012-04-16 08:55:49,720 Creating tool_version_association table failed: (OperationalError) (1050, "Table 'tool_version_association' already exists") u'\nCREATE TABLE tool_version_association (\n\tid INTEGER NOT NULL AUTO_INCREMENT, \n\ttool_id INTEGER NOT NULL, \n\tparent_id INTEGER NOT NULL, \n\tPRIMARY KEY (id), \n\t FOREIGN KEY(tool_id) REFERENCES tool_version (id), \n\t FOREIGN KEY(parent_id) REFERENCES tool_version (id)\n)\n\n' () Added 0 rows to the new tool_version table. done 91 -> 92...
Migration script to create the migrate_tools table.
0092_add_migrate_tools_table DEBUG 2012-04-16 08:55:49,920 Creating migrate_tools table failed: (OperationalError) (1050, "Table 'migrate_tools' already exists") u'\nCREATE TABLE migrate_tools (\n\trepository_id VARCHAR(255), \n\trepository_path TEXT, \n\tversion INTEGER\n)\n\n' () 0092_add_migrate_tools_table DEBUG 2012-04-16 08:55:49,920 Creating migrate_tools table failed: (OperationalError) (1050, "Table 'migrate_tools' already exists") u'\nCREATE TABLE migrate_tools (\n\trepository_id VARCHAR(255), \n\trepository_path TEXT, \n\tversion INTEGER\n)\n\n' () done
the bizarre thing is, all three tables: 'migrate_tools', 'tool_version_association','tool_version' are present.....well, this explains the error: 'OperationalError 1050, "Table 'migrate_tools' already exists" '....but why were the commands executed a second and third time? - what happened during the first execution?
I can execute the three create statements without problems in a dummy database on the same MySQl server (Server version: 5.1.41-3ubuntu12.10)
and if I compare the "describe migrate_tools" outcome for the real database (galaxy_xenon1) and the dummy database (galaxy_xenon1_old), I don't see a difference and it corresponds to the 'create statement'
mysql> describe galaxy_xenon1.migrate_tools; +-----------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------------+--------------+------+-----+---------+-------+ | repository_id | varchar(255) | YES | | NULL | | | repository_path | text | YES | | NULL | | | version | int(11) | YES | | NULL | | +-----------------+--------------+------+-----+---------+-------+ 3 rows in set (0.00 sec)
mysql> describe galaxy_xenon1_old.migrate_tools; +-----------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------------+--------------+------+-----+---------+-------+ | repository_id | varchar(255) | YES | | NULL | | | repository_path | text | YES | | NULL | | | version | int(11) | YES | | NULL | | +-----------------+--------------+------+-----+---------+-------+ 3 rows in set (0.00 sec)
mysql>
Has anybody seen similar issues or can shed some light on our problems?
Thank you very much for your help
Hans