I tend to use database dumps (POSTGRESQL and MYSQL) in the repository for
test data, but not for production data. Its good to be able to recover a
test database that is synced to a particular code revision.
However the test dumps I use tend to be 1 or 2 megs at the most and are all
ascii.
----- Original Message -----
From: "Bruce Elrick" <bruce.elrick@entropyreduction.ca>
To: "Bruce Elrick" <bruce.elrick@entropyreduction.ca>
Cc: "Daniel Patterson" <danpat@adaptiveinternational.com>;
<dev@subversion.tigris.org>
Sent: Monday, June 23, 2003 2:51 PM
Subject: Re: OT: Configuration management for stateful data
> 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.
>
> precluded
>
> > 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
>
>
---------------------------------------------------------------------
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:58:46 2003