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
Received on Mon Jun 23 15:52:20 2003