Posted by Jim Kirkpatrick on September 22, 2011 at 3:20pm
7 followers
| Project: | Block Class |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
We were getting a lot of:
User warning: Table 'dev.block_class' doesn't exist query: SELECT css_class, module, delta FROM block_class in _db_query() (line 148 of /---/www/includes/database.mysql.inc).
No amount of uninstalling and re-installing would actually install that table. Rolled back to 6.x-1.3 and it installed immediately.
Can't see anything in the code... It's possible our SVN messed up but thought it best to add a ticket in case.
Comments
#1
Thanks, I've disabled the dev snapshot for now until I've time to work on it.
#2
I'm still running into the problem and it's because of this:
user warning: Specified key was too long; max key length is 1000 bytes query: CREATE TABLE block_class ( `module` VARCHAR(255) NOT NULL, `delta` VARCHAR(255) NOT NULL, `css_class` VARCHAR(255) NOT NULL, PRIMARY KEY (module, delta) ) /*!40100 DEFAULT CHARACTER SET utf8 */ in includes/database.inc on line 550.
If you do a Google search on the error, you'll find it's a known issue with MySQL. However, there are other modules that are reporting the same problem and their install schema had to be fixed in order to make it work.
To get around it, I went into PHPMyAdmin and manually created the table via the query that was created. However, I do not recommend this unless you are comfortable with PhPMyAdmin and the Drupal DB.
#3
#4
Current code of block_class in the repository has been completely hi-jacked.
Attached patch fixes the schema of block_class in 6.x-1.x, which is the scope of this issue. There seems to be a new 6.x-2.x branch, but that's not the point here.
#1020846: 7.x-1.x fails to install database schema ("Specified key was too long") needs to account for this fix afterwards.
#5
+++ b/block_class.install@@ -55,48 +50,70 @@ function block_class_uninstall() {
'length' => '255',
This should be 64 in length
+++ b/block_class.install@@ -55,48 +50,70 @@ function block_class_uninstall() {
'length' => '255',
This should be 32 in length
+++ b/block_class.install@@ -55,48 +50,70 @@ function block_class_uninstall() {
'size' => '255',
This should be length instead of size.
#6
I ran into this problem using drush make which fetched the 6.x-1.4-beta1 which is really not a decent beta :(
Could you remove this 6.x-1.4-beta1 version?
#7
re #5: No, existing module updates must not be changed.
#8
@sun Yes and no.
You are right not to change an existing hook_update_N. Sorry about that.
But the patch then need a new hook_update_N to make sure the index are not exceeding 255 chars.
See http://drupalcode.org/project/block_class.git/commitdiff/965e79bf487f274...
This commit contains parts of patch #4 :(
So the patch still needs work against the latest dev version. http://drupalcode.org/project/block_class.git/blob/refs/heads/6.x-1.x:/b...
Darn.
#9
Sorry, but it doesn't seem like you properly looked at this patch.
+++ b/block_class.install@@ -55,48 +50,70 @@ function block_class_uninstall() {
+function block_class_update_6101() {
The patch already contains a new update to fix the mess.
I've tested both the update from the current version as well as the installation from scratch.
#10
Ok ... I'm now testing the upgrade / update process.
Updating from 6.x-1.3 to 6.x-1.x
Running update.php fails on
<?phpblock_class_update_6100()
?>
notice: Undefined index: varchar:255 in /Users/clemens/Sites/drupal/d6/www/includes/database.mysql-common.inc on line 143.user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NOT NULL' at line 1 query: ALTER TABLE block_class CHANGE `css_class` `css_class` NOT NULL in /Users/clemens/Sites/drupal/d6/www/includes/database.mysql-common.inc on line 528.
user warning: Specified key was too long; max key length is 1000 bytes query: ALTER TABLE block_class ADD PRIMARY KEY (module, delta) in /Users/clemens/Sites/drupal/d6/www/includes/database.mysql-common.inc on line 382.
With readable output
The following queries were executed
block_class module
Update #6100
ALTER TABLE {block_class} DROP PRIMARY KEY
ALTER TABLE {block_class} CHANGE `module` `module` VARCHAR(255) NOT NULL
ALTER TABLE {block_class} CHANGE `delta` `delta` VARCHAR(255) NOT NULL
Failed: ALTER TABLE {block_class} CHANGE `css_class` `css_class` NOT NULL
Failed: ALTER TABLE {block_class} ADD PRIMARY KEY (module, delta)
This is due to
<?phpfunction block_class_update_6100() {
...
db_change_field($status, 'block_class', 'css_class', 'css_class',
array(
'type' => 'varchar',
'size' => '255',
?>
Size is not a valid field attribute
<?php// Restore the primary key.
db_add_primary_key($status, 'block_class', array('module', 'delta'));
?>
Fails due to key too long.
#11
Doing the same from #10 for the update
From 6.x-1.3 to 6.x-1.x + patch from #4
notice: Undefined index: varchar:255 in /Users/clemens/Sites/drupal/d6/www/includes/database.mysql-common.inc on line 143.user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NOT NULL' at line 1 query: ALTER TABLE block_class CHANGE `css_class` `css_class` NOT NULL in /Users/clemens/Sites/drupal/d6/www/includes/database.mysql-common.inc on line 528.
user warning: Specified key was too long; max key length is 1000 bytes query: ALTER TABLE block_class ADD PRIMARY KEY (module, delta) in /Users/clemens/Sites/drupal/d6/www/includes/database.mysql-common.inc on line 382.
user warning: Can't DROP 'PRIMARY'; check that column/key exists query: ALTER TABLE block_class DROP PRIMARY KEY in /Users/clemens/Sites/drupal/d6/www/includes/database.mysql-common.inc on line 394.
With readable text
ALTER TABLE {block_class} DROP PRIMARY KEY
ALTER TABLE {block_class} CHANGE `module` `module` VARCHAR(255) NOT NULL
ALTER TABLE {block_class} CHANGE `delta` `delta` VARCHAR(255) NOT NULL
Failed: ALTER TABLE {block_class} CHANGE `css_class` `css_class` NOT NULL
Failed: ALTER TABLE {block_class} ADD PRIMARY KEY (module, delta)
Update #6101
Failed: ALTER TABLE {block_class} DROP PRIMARY KEY
ALTER TABLE {block_class} CHANGE `module` `module` VARCHAR(64) NOT NULL
ALTER TABLE {block_class} CHANGE `delta` `delta` VARCHAR(32) NOT NULL
ALTER TABLE {block_class} ADD PRIMARY KEY (module, delta)
So patch #4 needs work as the primary key didn't made it.
(patch is underway)
#12
I moved the update_6101 update to update_6102
Next inserted a fix for update_6100 into update_6101.
Removed the failing field update and index key update_6100
The update now only fails on dropping the primary key.
#13
ok, that complicates things a bit.
6.x-1.3 didn't contain any updates at all, and a very bogus schema on top: http://drupalcode.org/project/block_class.git/blob/a58723ec455a8fa7a84f2...
Latest 6.x-1.x, however, already contains update 6100, and I can only guess that many updated to that snapshot as the latest stable is quite old and buggy.
This means we need to support two update path branches. Not a big issue, Drupal core had to deal with more complex scenarios already.
Attached patch empties out 6100 (which possibly ran for users on 6.x-1.x already) and adds a new update 6101 (which will run for all users).
I hope you don't mind a format-patch. Only the second commit is new.
#14
+++ b/block_class.install@@ -55,38 +55,9 @@ function block_class_uninstall() {
+ // Removed. This schema update made new installations fail due to a too long
+ // primary key index. Since many users updated to it already, the corrected
+ // schema change has been moved to block_class_update_6101() now.
Should be something like 'updates from 6.x-1.3' not 'new installations'
Ehrm ...
is abracadabra to me. But nm. We now agree on update_6100 was wrong.
If you want people to review the patch against 6.x-1.x a 'normal' patch would be better I guess.
#15
Sorry, ok, regular patch attached, including suggested comment tweak.
#16
Patch from #15 looks ok.
Attached a patch against 6.x-1.3 as 6.x-1.4-beta1 is bad and drush_make grabs 6.x-1.4-beta1 for some reasons.Edit: The 6.x-1.3 patch is not applicable to 6.x-1.3.tar.gz download as that was before the git migration.
#17
New patch applicable with drush make
; drush_make grabs 6.x-1.4-beta1 which is not publish yet and buggyprojects[block_class][version] = 1.3
projects[block_class][patch][] = "http://drupal.org/files/block_class-6.x-1.3-install-schema-17_0.patch"
(Lesson learned ... patching against non git version the $Id$ is expanded and this part was used as a patch context)
#18
To clarify once more: #15 is the patch to commit to 6.x-1.x.
#19
Any updates? This is a critical bug.
#20
I'm afraid that @berenddeboer said in #1 this will take some time :(
According to http://drupal.org/project/usage/block_class people are (fortunately) stuck to 6.x-1.3 version. (Only drush make users feel the pain :p)
#21
@sun: I will grant you commit access. Feel free to commit any changes you like. I could certainly use a co-maintainer.
#22
Patch #15 applied in git.
#23
Automatically closed -- issue fixed for 2 weeks with no activity.