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

#1 Re: Managing database updates Posted by dkg (216.254.xx.xx) on Fri 2 Feb 2007 at 05:28 For one project i've worked on, we decided that the file containing the database schema could never be edited, just appended to. this makes the schema difficult to read for folks who expect the current schema to be visible, but it actually makes the upgrades really easy: just feed the diff between revisions (without the diff markup) directly into the database engine on the live site. If folks want to see a clean view of the current schema, that's something you can generate: just create an empty database, feed it the schema file, dump the schema, and drop the database. This strategy treats the schema history like any other source file under revision control: if you want a processed/compiled version you need to apply some post-processing to get it. You could even include a makefile to auto-generate it (assuming you have database creation privileges) before packing the code for publication.

Username:	Anonymous
Title:
Your Comment:
Posting Format:	BBCode HTML Text Plain Text Textile

Inappropriate comments will be removed.

Username:

Password:

[ Advanced Login ]

Register Account