[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: OT: Configuration management for stateful data

From: Bruce Elrick <bruce.elrick_at_entropyreduction.ca>
Date: 2003-06-23 15:20:07 CEST

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.


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?

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.