This is the tracker for the Core of the Nucleus CMS-project (Nucleus CMS Website)
FS#67 — Add resilency to upgrade scripts
Attached to Project— Nucleus Core
Opened by Andrew Black (Frankenstein) - Monday, 23 May 2005, 02:52AM
Last edited by Wouter Demuynck (karma) - Saturday, 23 July 2005, 10:28AM
Opened by Andrew Black (Frankenstein) - Monday, 23 May 2005, 02:52AM
Last edited by Wouter Demuynck (karma) - Saturday, 23 July 2005, 10:28AM
| Improvement | |
| Management → Upgrade | |
| CLOSED | |
| Andrew Black | |
| All |
| Medium | |
| Normal | |
| CVS | |
| 3.3 | |
| Undecided | |
 |
A problem with the upgrade scripts as they are written now is they assume that all queries happen successfully.
If a given query doesn't occur correctly, the database version will be bumped despite this fact, likely wrecking havoc with the installation. (*knows this from experience*).
Therefore, for each query to execute, the upgrade script should check if the corresponding change has already happened, only try to execute the script if it hasn't, and only update the DatabaseVersion if no errors have occurred.
cleanup.diff
cleanup2.diff
If a given query doesn't occur correctly, the database version will be bumped despite this fact, likely wrecking havoc with the installation. (*knows this from experience*).
Therefore, for each query to execute, the upgrade script should check if the corresponding change has already happened, only try to execute the script if it hasn't, and only update the DatabaseVersion if no errors have occurred.
cleanup.diff
cleanup2.diff
Closed by Andrew Black (Frankenstein)
Date: Saturday, 06 August 2005, 11:38PM
Reason for closing: Implemented
Additional comments about closing: Committed to CVS by karma on 3 Aug.
I've attached a possible cleanup for the upgrade code that should make it a little more robust. It's one of my 'works in theory, but untested' scripts, so theres a chance I have a typo or two in it.
Any idea where I could find an example 0.95 schema with a little sample data to test the updated code with?
The cleaned up code checks almost every change before running it to see if it already has been done, and only updates the token that the checkinstall script checks if no errors have occurred.
I've checked cleanup2.diff and committed these changes to CVS. Everything looks fine.
I did fix some copy-paste issues where upgrade_checkIfCVExists was called with a configuration value name other than the one being added.
As for the comment about the cblog column addition to nucleus_comment in upgrade1.5.php: the original code tried to limit the amount of update queries by executing max. 1 'UPDATE' query for each itemid. If there were 1000 items with 100 comments each, only 1000 UPDATE queries would be executed. The new implementation looks like it's also going to work. No need to spend much time on this: I don't suspect anyone is using versions older than 1.5