[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:51:19 CEST

Holy smokes my typing is bad...sorry for all the typos. I should go
back to bed.

Bruce Elrick wrote:

> 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.

must contain application/business 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.

may be able to

> 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

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:52:20 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.