[DGD] Managing a persistent mud.

[Raymond Jennings]

Don't forget, if you have an object that inherits another object, it's
entirely possible that you may need to upgrade the code (and associated
data) in the leaf object, but not an inherited object.  Or vice versa.

A good upgrade process should be able to take into account when only part
of an object's inheritance tree needs its associated data upgraded.

On Tue, Sep 8, 2015 at 7:43 PM, Raymond Jennings <shentino at gmail.com> wrote:

> I'm vicious with nuking old code and data.
>
> I did however have to implement a check before upgrading and cause an
> error before recompiling anything.
>
> On Tue, Sep 8, 2015 at 7:10 AM, <bart at wotf.org> wrote:
>
>> Hi Gary,
>>
>> I can only comment on how I handled this in the past while I was still
>> maintaining Gurbalib.
>>
>> First of all, versioning of the data in objects:
>>
>> What I used to do is:
>> 1. have a variable containing the current version of the data (just a
>> number)
>> 2. have a #define in the code of the object to indicate the version
>> required
>> by that code
>>
>> Upgrade function would check both, and perform an upgrade of the data
>> based on
>> the difference between those numbers.
>>
>> Using this, you can do all required conversions.
>>
>> As you also noted, your upgrade function will grow and get more complex
>> over
>> time, and it is a good idea to remove old conversions after some time. How
>> much time is really upto you, typically I kept things around for at least
>> a
>> few versions, and also added some code to cause an error when the
>> difference
>> is too big (current data version is too old).
>>
>> This error would indicate the last revision (svn version in my case) of
>> the
>> code that can still do the conversion, so when reverting to an old
>> statedump,
>> you'd also roll back to that specific svn/git/whatever revision of the
>> code,
>> perform the required upgrades again, and then update the code to the
>> latest
>> revision from svn/git/whatever, rinse and repeat for all required data
>> upgrades.
>>
>> Bart.
>>
>> On Mon, 07 Sep 2015 21:19:07 +0100, Gary wrote
>> > (Posting this again as the one I sent earlier today appears to have gone
>> > AWOL, apologies if this results in a double post)
>> >
>> > Hey All,
>> >
>> > I've been looking over phantasmal and a few other mud libs for DGD to
>> > see how they handle upgrading objects via objectd on a persistent mud.
>> >
>> > As far as writing an upgrade method to bring objects up to date that
>> > might need data transformations to make old objects compatible with the
>> > newest code, that makes sense. Still plenty of code to run through
>> > and understand, but in general it makes sense.
>> >
>> > I take it, if there's new code in a create method (for example to store
>> > a reference to the driver object for other methods to use), that the
>> > reference would also need obtaining in the upgrading method since
>> > some pre-existing objects will not receive a create call (as they
>> > already exist).
>> >
>> > This brings me to a question regarding object versioning.
>> >
>> > If the need arises to roll the mud back to an earlier snapshot, the
>> > objects would be in states that any recent upgrading method may no
>> > longer cover.
>> >
>> > This leads to the introduction of an object version flag that can be
>> > incremented any time a code change needs to run some custom upgrade
>> > logic. Allowing the upgrade method to take an object from any prior
>> > version up to the latest supported by that code.
>> >
>> > Before I head down a path that will potentially lead to an ever growing
>> > upgrade method in various objects, I'd be interested in hearing how
>> > others may have handled this.
>> >
>> > I guess this may be a policy question as much as a technical one, as
>> > it depends on how far back you/your user base would be willing to accept
>> > for a rollback in order to fix a critical issue. I'm particularly
>> > interested in any approaches that differ from the above method.
>> >
>> > Cheers,
>> >
>> > Gary
>> >
>> > ____________________________________________
>> > https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>>
>> --
>> http://www.flickr.com/photos/mrobjective/
>> http://www.om-d.org/
>>
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>
>