I can recreate my system from backup in
Seconds Minutes Hours Days Weeks Never tested Never backed up ( 447 votes ~ 6 comments )
You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.
To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.
This is the comment you were replying to, attached to the weblog Managing database updates
#2 Re: Managing database updates Posted by Steve (80.68.xx.xx) on Fri 2 Feb 2007 at 10:43 That is a pretty neat solution, which I guess does the job! That would suggest I have two files, the "initial" file which creates the tables, and then the "upgrade" file showing the changes which had been applied since that starting point. (The upgrades should be careful not to disturb any existing data). The only downside I see to this approach is that you really have to be careful that you don't run the upgrade.sql script when it no longer applies - hence your suggestion to use the diff. eg: Initial State CREATE TABLE `users` ( `id` INT(11) NOT NULL AUTO_INCREMENAT, `username` VARCHAR(25) NOT NULL DEFAULT '', ); Upgrade File UPDATE USERS SET username = 'skx' + username WHERE id=1; Running that more than once would be a bad thing. I think having versioned schemas would solve that problem. Keep the pristine starting point, and then create a new upgrade file for each new revision - these could then be used to upgrade from X to schema X+N, and since it would be scripted it would be possible to ensure things weren't run more than once. Steve
That is a pretty neat solution, which I guess does the job!
That would suggest I have two files, the "initial" file which creates the tables, and then the "upgrade" file showing the changes which had been applied since that starting point.
(The upgrades should be careful not to disturb any existing data).
The only downside I see to this approach is that you really have to be careful that you don't run the upgrade.sql script when it no longer applies - hence your suggestion to use the diff.
eg:
CREATE TABLE `users` ( `id` INT(11) NOT NULL AUTO_INCREMENAT, `username` VARCHAR(25) NOT NULL DEFAULT '', );
UPDATE USERS SET username = 'skx' + username WHERE id=1;
Running that more than once would be a bad thing.
I think having versioned schemas would solve that problem. Keep the pristine starting point, and then create a new upgrade file for each new revision - these could then be used to upgrade from X to schema X+N, and since it would be scripted it would be possible to ensure things weren't run more than once.
Steve
Posting Format:
Inappropriate comments will be removed.
Some help on entry formatting is available
Username:
Password:
[ Advanced Login ]
Register Account
