Dale Newfield wrote:
Steve Jorgensen wrote:
Well, besides being able to back out the changes, it has a standard
way of determining the current database schema version, and applying
all the migrations necessary, regardless of how far behind (or not)
the production environment has become.
I don't understand how this is always guaranteed to be possible...
...for example if you add a column that is "not null", but doesn't
have a default value, no script magic can know what new values are
appropriate...
There are certainly kinds of changes that can't be supported by a
migration system, but one simply does not implement those kinds of
changes - at least not after previous versions of an application are in
production.
If you implement a schema change (as you describe) such that you now
require a data item that was never known or required before, and there
is no appropriate default, then you've created a situation where
production data can never be upgraded by any means whatsoever - don't do
that <g>.
The closest thing to that which does happen in the real world is adding
a new required foreign key linking to a newly created table. In this
case, one must insert some kind of default item into the new table, and
link to that record by default. Think of it as the relational
equivalent of the Null Object pattern.
- Steve J.
begin:vcard
fn:Steve Jorgensen
n:Jorgensen;Steve
org:Vigilan, Inc.
adr:;;9375 SW Commerce Circle, Suite A1;Wilsonville;OR;97070;USA
email;internet:[EMAIL PROTECTED]
title:Senior Development Engineer
tel;work:503-682-8828 Ext. 226
url:http://www.vigilan.com
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
