[Zope3-dev] class lifecycle management/missing attributes

[Tres Seaver]

On Tue, 2003-07-01 at 23:31, Garrett Smith wrote:
> Peter Simmons wrote:
> > Hi,
> > 
> > Just out of interest why is an upgrade script like Tres is suggesting?
> > 
> > We schedule upgrades so that users aren't using the system, is that
> > not possible for your system?
> > 
> > I figure there is a good reason but I can't think of it and was
> > wondering. 
> 
> I'm not rejecting that option -- just curious as to the alternatives.
> 
> In some environments, there is no good opportunity to perform these
> upgrades -- 24/7 and all that.
> 
> I've use 'lazy' upgrades (automagical, I suppose :-) in other
> applications, and they've worked very well. The use, though, was
> generally limited to adding new properties. Existing properties were
> never deleted or modified, which elimited the cruft that Tres mentioned.

Just for clarity:

  - If adding an immutable attribute (e.g., a string, an int, etc.),
    then putting the "default" value at class scope works well:

     class FooContent(Persistent):
         _bar = 0
         def __init__(self, bar):
             self._bar = bar

  - If the new attribute needs to be mutable, then a variation which
    can be made to work is to write an accessor for the attribute which
    does the "upgrade in place":

     class FooContent(Persistent):
         _bar = None
         def __init__(self, baz):
             self._bar = Bar(baz)
         def bar(self):
             if self._bar is None:
                self._bar = Bar() # write-on-read
             return self._bar

    The majyk inside 'bar' is part of what I meant by cruft:  unless
    you force every instance to be upgraded, you can never safely
    remove it.

> But I'll defer to his wisdom on this one -- I have zero experience with
> ZODB, Python persistence, etc.
> 
> Is there a facility to quickly track down objects of a particular class
> in the ZODB? It would seem invaluable to be able to perform operations
> on a set of objects based on class. For obvious reasons, this sort of
> thing is taken for granted in RDBs.

The usual modes in Zope2 are to use a recursive container walk (using
'objectValues') or to use a catalog search.  In Zope3, one might just
iterate over the objects in the objectHub, looking for the instances
whose '__class__' matched the upgraded one.  To optimize such searches,
I would try wiring up FieldIndex on the '__module__' and '__name__' of
the instance's '__class__'.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com