[DGD] Upgrade management

[bart at wotf.org]

On Thu, 20 Mar 2014 20:28:31 -0700, Raymond Jennings wrote
> Heck, why don't I ask about this on the list?  that's what it's for IIRC.
> 
> Presently, every time a program is compiled, the owning subsystem's initd
> is asked for a "toucher" function.
> 
> Later, when a non inheritable is compiled that inherits that program,
>  it and all its clones are flagged with call_touch, which when triggered
> invokes the toucher function in place before the object is manipulated.
> 
> Issues I'm trying to solve (and having SOME luck figuring out)
> 
> * enforcing serial upgrades so that data isn't lost by skipping a migration

Versioning of your data seems the solution here.

What I've been using for this so far is a combination of 2 things:
- a variable containing the version of the current data
- a define containing the version of the data expected by the current code.

This allows the 'touchers' to 'know' what work has to be done:
- the define will have changed as soon as the new code is compiled
- checking the version variable against the define will tell which data
conversions are needed
- after conversion the version variable should be updated with the current
value of the version define

As a consequence, you'll be leaving some conversion code around for a while in
the toucher function until such time that you are sure you no longer need it.

> * efficiency so that touchers aren't called redundantly.

Preventing all redundant calls means knowing beforehand what work they'll be
doing. I don't think this will work, and it also means you'll be centralizing
knowledge about internal data in objects in a place outside those objects. I
don't like this approach, but technically it could work for all I can tell.

But the mechanism described above does prevent the touchers from doing actual
work when there is no work to do.

One refinement you can make is use the blueprint of an object for 'knowledge'
about data conversion by the toucher function, and only mark clones if the
blueprint indicates this is required.

> 
> But of coruse suggestions aren't limited to these issues.  Any thoughts?

Plan carefully on how many prior versions of your data and code you want to
support for data conversions. Don't be too strict in this, supporting at least
a few different versions will be a life-saver when you ever have to revert to
an older statedump and need to redo an upgrade.

Bart.
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/