I know R/3 does table copies within the database (as opposed to dump &
load). That is, copy current table to temporary, drop original, rebuild
table with new properties, copy from temporary to new, drop temporary.
Obviously the last portion must application/business contain logic. If
the table changes are simple (add a field that is allowed to be null)
and the RDBMS allows it, you make be able to simply change the table in
situ. However, even such a simple change may be procluded if having a
large number of the old records with nulls in the new field makes the
application less useful. For example, you might actually have to run a
data cleansing project where you get humans to go through that data and
provide values for the new field on a record-by-record basis. Maybe you
can do that before the code upgrade, maybe you can do it after.
In terms of whether it is practical, I don't think it really matters: it
is necessary. If anything stops you from doing it, then you can't
change upgrade/change, full stop.
Cheers...
Bruce
Daniel Patterson wrote:
>Greetings all,
>
> I'm looking for advice on the best practises for configuration
> management of stateful data.
>
> This situation comes up in a few different places, but the
> best example (and the one I have right now) are database
> schema changes between software releases.
>
> For stateless portions of the system (i.e. the application
> code), it's easy to overwrite, or drop/replace (in the case
> of database stored procedures). However, stateful portions
> (i.e. database tables with data in them, configuration files,
> any other stateful information that may undergo a schema change),
> the usual configuration management procedures don't apply.
> You can't drop 12 months of data from your database because
> you need to rename a relational table....
>
> A bit of searching around on google didn't reveal anything,
> but it's hard to know if I'm searching for the wrong thing or
> if nothing really exists.
>
> I've thought a bit about the process that Subversion takes
> (a dump into a known format followed by a reload), but in
> our situation, building a tool like that is impractical.
>
> Has anyone done any deep thinking about this topic and come
> up with any good patterns to follow?
>
>daniel
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 23 15:21:30 2003