[DGD] Managing a persistent mud.
Gary
gary at mups.co.uk
Mon Sep 7 22:19:07 CEST 2015
(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
More information about the DGD
mailing list