[ZODB-Dev] Support for graceful ZODB Class renaming

[Pieter Nagel]

On Sun, Jan 19, 2003 at 11:50:09AM +0000, Toby Dickenson wrote:

> Only if you have broken the rule:
> 
> > >      A bother with this approach is that the aliases need to be
> > > maintained as long as the old pickles exist in the database, which could
> > > be indefinitely.

I do not consider maintaining old pickles conforming to code from a database's
archaelogical past to be a "rule" to be followed.

I consider it a *liability* to be avoided at all costs.

I have this mental model of an invariant that asserts: "All objects in the
database conform to the code", meaning:
  1) dotted classnames of the pickles correspond to the classes name
     and module.
  2) No pickles whose corresponding classes have been removed from the
     code exist anymore.
  3) The attribute names are the same as what the latest version of the
     code creates. [1]
  4) Any other application-level constraints one cares to define.

During development the invariant of the production database and the
invariant of the development code diverge. 

However, at some point the new code is deployed, and at that time it is
important, IMHO, to ensure that the production database (which satisfied
the old invariant), is atomically transformed either to conform to the new
invariant, or rolled back to exactly where it was (at which point one has
some fixing to do in one's development code).

As far as this thread goes, you can see that Jim Fulton's proposal 2 (a
utility to fix the class names of all the pickles in the database) is a
subset of the bigger problem of maintaining the invariant.

If one objects that this transformation is too complicated, I would say
that one is in deep trouble because essentially it means one has no clue
what kind of data is "out there" that the code should handle; and how do
you know whether ad-hoc __getstate__ on-demand transformations work then?

If one's database is so big that this transformation is too expensive,
then I'd say one is playing in a totally different league, and one needs
to pull out bigger guns to manage the complexity, and good luck to you :-)

-- 
     ,_
     /_)              /| /
    /   i e t e r    / |/ a g e l
    http://www.nagel.co.za

[1] Due to the dynamic nature of Python one could, of course, merely
broaden one's notion of what the legal attribute names on an object are to
be the superset of all the attribute names the object ever had, and write
code with lots of hasattr's all over the place.

But this would be cheating. The whole goal of this excercise is to
maintain simplicity. The simplicity need not consist of a *statically*
declared list of legal attributes, like in C++ or Smalltalk; it should,
however be *simple* and clear.