Re: persistence and __setstate__

Jeremy Hylton wrote:

...

> Here are some sketches of other approaches:

I should mention that there are auditing issues. Transactions
keep meta-data, typically including the user and URL of the request
that executed them. This auditing information is sometimes very important



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

Or maybe a state version id.

Another issue is deciding what the transaction meta-data should be.
Clearly, the transaction doesn't have anything to do with the current
user or request URL.


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

I don't like writing as a result of a setstate because it turns "read"
requests into "write" requests, which feels like a very bad thing to
do. It is certainly bad from an auditing point of view.


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

Yup.

Jim


-- 
Jim Fulton           mailto:[email protected]       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org