[DGD] Managing a persistent mud.

[Raymond Jennings]

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
>