Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
libraries_update_7200() always fails for me:
Failed: PDOException: SQLSTATE[HY000]: General error: 1005 Can't create table 'd7git.cache_libraries' (errno: -1): CREATE TABLE {cache_libraries} ( `cid` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.', `data` LONGBLOB NULL DEFAULT NULL COMMENT 'A collection of data to cache.', `expire` INT NOT NULL DEFAULT 0 COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` INT NOT NULL DEFAULT 0 COMMENT 'A Unix timestamp indicating when the cache entry was created.', `serialized` SMALLINT NOT NULL DEFAULT 0 COMMENT 'A flag to indicate whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), INDEX `expire` (`expire`) ) ENGINE = InnoDB DEFAULT CHARACTER SET utf8 COMMENT 'Generic cache table for caching things not separated out...'; Array ( ) in db_create_table() (line 2686 of /home/rfay/workspace/d7git/includes/database/database.inc).
I've experimented with a few variants of the update function, including
function libraries_update_7200() {
if (!db_table_exists('cache_libraries')) {
$specs = libraries_schema();
db_create_table('cache_libraries', $specs['cache_libraries']);
}
}
But nothing seems to get me anywhere.
Comment | File | Size | Author |
---|---|---|---|
#4 | libraries.improve_update_7200-2.patch | 978 bytes | tstoeckler |
#2 | libraries.improve_update_7200.patch | 487 bytes | rfay |
Comments
Comment #1
tstoecklerHmm... I just retried the update on my local install and everything went through fine. So I don't really know where to look for the error.
You're proposed update function is correct, though. We currently call drupal_get_schema_unprocessed() directly in the update function (instead of libraries_schema()), and because of that the table description is wrong for people who upgraded (like in your error message). Not that that will break anything (and I don't think we should add a second update function for that), but we should change the (existing) update function nonetheless.
Comment #2
rfayTLDR; This was an inndb/mysql error that was fixed by attempting to drop the database, actually having to remove the directory (which contained cache_libraries.ibd). The patch you liked is attached, and that's why it's set to needs review although it's fixed for me. I note that the successful update happened with this in place, but I wouldn't assume anything from that.
From http://dev.mysql.com/doc/refman/5.0/en/innodb-error-codes.html:
I also see this stackoverflow item, but I don't see anything useful from
show engine innodb status;
Finally, I note DamZ's response on http://drupal.org/node/1010764, in which the issue there was actually an INNODB failure.
AHA!
I dumped my database, intending to drop it and recreate it. Then I dropped it. But got
So I went to see what was in there:
So there was a remnant of some previous cache_libraries somehow left there, either as a result of upgrades or...
Now, having recreated my database, the update succeeds.
In case you're interested, I'm attaching the patch from the OP; otherwise this can be "fixed". Thanks so much for your responsiveness.
Comment #3
tstoecklerThanks very much! What a terrible debugging crusade!!! Poor you...
I added a little comment to the update function, in case people wonder why they have two table comments for the same table on two different sites (for example). I also noticed that tables in Drupal core end their table comment with a period, so I added that. I hope no kittens were harmed.
Committed the attached patch.
http://drupal.org/commitlog/commit/10030/7497d70a42f683f27bded70571e5c4b...
Thanks again!
Comment #4
tstoecklerHere's the patch.