I just upgraded, and I have the following error messages when updating the db:
Update #158
Failed: ALTER TABLE {old_revisions} ADD done tinyint(1) NOT NULL DEFAULT 0
Failed: ALTER TABLE {old_revisions} ADD INDEX (done)
Update #159
UPDATE {sequences} SET id = 54 WHERE name = '{node_revisions}_vid'
Failed: ALTER TABLE {old_revisions} DROP done
I can't find anything relate to the old_revisions table. It's not in the database definition, nor did any search on google or on drupal.org bring up anything relevant.
B.
Comments
Comment #1
killes@www.drop.org commentedI think you created a cvs install some time after the first revisions patch went in. This first patch created the old_revisions table. I don't think anybody has a real site that will have this problem.
Comment #2
beginner commentedYou are right.
I see CREATE TABLE {old_revisions} in system_update_146 dated 2005-08-25 and I created the cvs install in september.
I have a few questions, though:
I did run update.php, then: why the tables were not created at that time? (it may be my fault: I may have made a mistake then).
I cannot see that those tables are created in a fresh 4.7 install. I assume {old_revisions} is only needed for backward compatibility with a 4.6 install.
The site I updated is actually live. I created the site just after the code-freeze was announced in september, so I skipped 4.6 altogether (I know, I know... ;-) ).
In those conditions, is it safe for me to ignore this error ( {old_revisions} not created and last DB update error message)? Or should I browse the source of updates.inc, looking for this and other DB updates that have not been made properly?
thanks.
Comment #3
killes@www.drop.org commentedIf you did create the site in September then you would not run update.php at all and the update that created the old_revisions table.
Comment #4
beginner commentedSo, what about the error message? Do we need those tables or not? Do I need to create them "manually"?
Comment #5
killes@www.drop.org commentedThe table is created in update 146 and holds old revisions that were created using the old revision table. For core node types, these old revisions are put into the node_revisions table in update 158/159. Non-core modules will need to create separate update scripts to retrieve their revisions.
A possible fix could be to create this table in update 158 if it does not exist. Don't know if this would work with pgsql.
Comment #6
Cvbge commentedIt's not trivial for postgres.
This error can't happen if you upgrade from 4.6. If you're using cvs - you should be ready to have some problems (and this one is completly safe afaik).
IMO this is not worthy fixing.