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