Re: persistence and __setstate__

[email protected] (Barry A. Warsaw) Wed, 31 Jul 2002 11:31:13 -0400
Newsgroups gmane.comp.python.zope.zodb4
Message-ID <[email protected]>
>>>>> "JH" == Jeremy Hylton <[email protected]> writes:

    JH> If you put code in the __setstate__ to handle object
    JH> evolution, that code will be executed every time the object is
    JH> loaded until there is a transaction that also modifies the
    JH> object.  Doesn't sound too pleasant, but also sounds
    JH> unavoidable.

    JH> Here are some sketches of other approaches:

    JH> - The database could provide a mechanism to register an object
    JH>   transform function that is executed when an out-of-date
    JH> object is loaded.  The transform could execute in a separate
    JH> transaction.  The hardest part is probably providing a means
    JH> to identify which objects are out-of-date, presumably some
    JH> kind of class revision id.

Or attribute test(s).

    JH> - It should be possible to provide some workaround to register
    JH> an
    JH>   object as modified within its __setstate__().  It's
    JH> certainly possible to explicitly register the object with the
    JH> Connection, although that doesn't mark it as changed.  But we
    JH> could add some hacks.

    JH> A potential concern for any solution: If the object is updated
    JH> on demand, it is probably important to execute the change as a
    JH> separate transaction.  If you don't, then the object update
    JH> gets mixed in with arbitrary updates to other objects, which
    JH> unnecessarily complicates undo.

That's a good point, and sounds like the first approach might work
better.  Would the __setstate__ itself be able to do a transaction
commit if it updated the object?  If so, that might be enough, if
inefficient for updating a large number of objects.  Hmm.

-Barry