Upgrade Fails to Execute Update Tasks
We recently attempted an upgrade from 1.6 to 1.12, and then to 2.1. The upgrade to 1.12 went fine, but we ran the upgrade script for 2.1, we started to see errors like these:
...
Do you wish to run all pending updates? (y/n): y
Executing hosting_alias_update_6203 [success]
ALTER TABLE {hosting_site_alias} CHANGE `redirection` `redirection` VARCHAR(255) NOT NULL [success]
Executing hosting_alias_update_6204 [success]
Unknown column 'db_name' in 'field list' [warning]
query: SELECT client, db_server, db_name, platform, profile, language as site_language, last_cron, cron_key, status AS
site_status, verified FROM hosting_site WHERE vid = 1065 database.mysqli.inc:134
...
Duplicate entry '127' for key 'PRIMARY' [warning]
query: UPDATE hosting_ip_addresses SET id=127 WHERE nid=707 AND ip_address='10.10.15.23'
database.mysqli.inc:134
...
UPDATE {hosting_ip_addresses} SET id=223 WHERE nid=836 AND ip_address='10.10.11.21' [error]
...
Even though the ALTER TABLE line above states it is a "success", examining the hosting_site_alias table, shows that the redirection field is still a TINYINT. Further, the error "Unknown column 'db_name' in 'field list'" error appears way before the ALTER TABLE for hosting_site table -- so there is some statements executed out of sequence, perhaps?
Anyone come across an issue like this during upgrade? How might one go about addressing these issues? We've checked DB permissions, and they are all fine -- after all the upgrade to 1.12 went fine. Nothing unusual on the DB server logs.
#1
Well, hosting_alias_update_6204() does call node_load which used the new db_name column. So we have to make sure that hosting_site_update_6202() runs before that.
I was already looking at hook_update_dependencies() but that only in D7... :(
The easiest fix is to manually manually add the db_name column as a varchar 64 in the hosting_site table and comment out the lines in hosting_site_update_6202() to prevent an error there.
#2
In the seqence of events above, hosting_alias_update_6203 and hosting_alias_update_6204 run before hosting_site_update_6202.
It is a little disturbing that the scripts returns "success" for an update that did not occur, and runs an update out of order.
So you're telling me the upgrade script isn't working like it should? And that the updates need to run manually? Are there any options for debugging?
I've these changes, and various UPDATEs similar to what I posted above. Are there any other updates I need to run manually?
ALTER TABLE hosting_site_alias CHANGE `redirection` `redirection` VARCHAR(255) NOT NULL ALTER TABLE hosting_context CHANGE `name` `name` VARCHAR(235) NOT NULL ALTER TABLE hosting_package_instance ADD `platform` INT NOT NULL DEFAULT 0 ALTER TABLE hosting_platform ADD `make_working_copy` INT unsigned NOT NULL DEFAULT 0 ALTER TABLE hosting_platform DROP release_id ALTER TABLE hosting_ip_addresses DROP INDEX vid ALTER TABLE hosting_ip_addresses DROP vid ALTER TABLE hosting_ip_addresses ADD `id` INT unsigned auto_increment DEFAULT NULL, ADD PRIMARY KEY (id) ALTER TABLE hosting_ip_addresses CHANGE `id` `id` INT unsigned NOT NULL auto_increment ALTER TABLE hosting_ip_addresses ADD INDEX nid (nid) CREATE TABLE hosting_ssl_cert_ips `cid` INT unsigned NOT NULL DEFAULT 0, `ip_address` INT unsigned NOT NULL DEFAULT 0, INDEX cid (cid), INDEX ip_address (ip_address) ) /*!40100 DEFAULT CHARACTER SET utf8 */ Executing hosting_server_update_6202 INSERT INTO hosting_ssl_cert_ips (cid, ip_address) SELECT cert.cid,server_ip.id FROM hosting_ssl_site ssl_site INNER JOIN hosting_ssl_cert cert ON cert.cid = ssl_site.ssl_key INNER JOIN hosting_ip_addresses site_ip ON site_ip.nid = ssl_site.nid INNER JOIN hosting_site site ON site.nid = ssl_site.nid INNER JOIN hosting_ip_addresses server_ip ON server_ip.ip_address = site_ip.ip_address INNER JOIN hosting_platform p ON site.platform = p.nid AND p.web_server = server_ip.nid WHERE ssl_enabled > %d AND site.status > %d GROUP BY cid ALTER TABLE hosting_site ADD `db_name` VARCHAR(64) NOT NULL DEFAULT ''#3
The 'problem' has been addressed in Drupal 7 by being able to specify in which order update hooks execute.
I don't think you need to run more updates manually, as e.g. hosting_alias_update_6203 does not call node_load.