Warning on update.php for dropping PRIMARY KEY [#497396]

I was running the 6.x-2.x-dev, June 10 version. I installed the June 20 dev version. When I ran update.php I got the following warning:

user warning: Can't DROP 'PRIMARY'; check that column/key exists query: ALTER TABLE drpl_node_galleries DROP PRIMARY KEY in /home/tally/public_html/SubDomain.pictest/includes/database.mysql-common.inc on line 386.

Below that was the following log message:

The following queries were executed
node_gallery module
Update #6201
    * Failed: ALTER TABLE {node_galleries} DROP PRIMARY KEY
    * ALTER TABLE {node_galleries} ADD PRIMARY KEY (nid)

I went to /node and got the WSOD with the message:

Fatal error: Call to undefined function node_gallery_get_types() in /home/tally/public_html/SubDomain.pictest/sites/all/modules/node_gallery/contrib/node_gallery_access/node_gallery_access.module on line 177

The WSOD appears on any page that displays Node Gallery data, including pages with Gallery teasers. I checked the admin/build/modules page and the Node Gallery module was unchecked and grayed out. The Node Gallery Access module was checked. I unchecked the Node Gallery Access module and saved. After the page refreshed, the Node Gallery module was checked. As expected, the WSOD disappeared from the other pages.

I re-ran update.php and no errors were reported.

Comments

Comment #1

Tally CreditAttribution: Tally commented 20 June 2009 at 20:16

I just updated a second site to the June 20 dev version. I verified that only the Node Gallery module was enabled on the admin module page. The access module was disabled. When I ran update.php after copying the module to the server, I got the same messages on the update.php screen at the end. I did not have any galleries, so I did not see any WSOD.

I checked the modules page and noted that the Node Gallery module was not enabled, but it was before the update. I saved the page with it remaining disabled and re-ran update.php. This time update.php completed successfully with no messages.

Comment #2

dddave CreditAttribution: dddave commented 22 June 2009 at 16:53

Can't DROP 'PRIMARY'; check that column/key exists query: ALTER TABLE node_galleries DROP PRIMARY KEY in C:\xampp\htdocs\D6\includes\database.mysql-common.inc on line 386.

I ran update.php a second time and no updates were done nor any messages appeared.

I also went on to the gallery pages but did not receive a WSOD nor any other error entry. Rebuilt the permissions and everything seems fine at the moment.....

Comment #3

dddave CreditAttribution: dddave commented 23 June 2009 at 22:04

Marked #499572: Upgrade from alpha8 to 9 failed as duplicate.

Comment #4

dddave CreditAttribution: dddave commented 23 June 2009 at 22:24

#2 happened with the dev from the 22nd.

Comment #5

dddave CreditAttribution: dddave commented 24 June 2009 at 14:41

Version:	6.x-2.x-dev	» 6.x-2.0-alpha10
Status:	Active	» Fixed

No problems with alpha 10.

Comment #6

Tally CreditAttribution: Tally commented 29 June 2009 at 18:40

Status:

Fixed

» Active

alpha 10 is the same as the Jun22 developer version. Only the Info files were changed to reflect the version number. There were no database table updates, so the error should not have appeared when updating the Jun22 developer version to alpha 10.

This error occurs when updating the database tables and is caused by the module install functions not working properly. I would prefer to hear that someone discovered the true cause of the error and determined and implemented the correct fix.

@dddave: Can you confirm that the error did not occur when installing alpha10 over alpha 9 without the intervening developer version? Can you confirm that the code was changed to correct the underlying problem? Otherwise, prematurely marking an issue as fixed will only impede the developers in fixing all the bugs in the code.

Comment #7

dddave CreditAttribution: dddave commented 29 June 2009 at 20:50

Sorry for setting this to fixed. I assumed that the problem was solved. I didn't look at code actually. I agree that in this case the issue shouldn't be marked fixed as long as there is no definite confirmation.

On the other hand it would be nice to know if this happened to somebody else. This module has already pretty high usage numbers even in its premature state and I think there should be more reports about this behaviour.

What do the maintainers think about this?