[DGD] Managing a persistent mud.

[bart at wotf.org]

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/