[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: Ryan Rawson <ryan_at_netidea.com>
Date: 2003-06-23 07:08:29 CEST


I work in ERP for a large company (that shall forever remain nameless),
and I think my experiences might benefit you a bit.

We use databases for our "stateful" data as you call it. I might call
it 'enterprise data' or 'business data'. When we do an upgrade to
database schemas usually its extending a table by adding a column, and
that can be done with a minimal outage (for live production systems)
and extending the database table. Without reloading the table (AFAIK,
I'm not a DBA). In any case, backups are your best friend when doing
any potentially destructive work on systems.

I think SVN has a role to play in management of the database "source" -
that is stored procedures (which suck) and schema specifications.

Management of the data itself is usually done with database backups,
save, restore, and all that good stuff.

I hope this helps.


On Sunday, June 22, 2003, at 09:58 PM, 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
> --
> Signature at:
> http://www.mel.au.adaptiveinternational.com/~danpat/signature.txt
> ---------------------------------------------------------------------
> 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 07:09:06 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.