Re: [ZODB-Dev] know the state of an object
Tim Peters wrote: I'm developing a ZODB based Collection Management software, and, for a bunch of reasons, i have to know the list of modified objects before the current transaction commit. Looking around seems there is no a public API to obtains this list That's true. How hard would it be to expose? Would there be any performance implications? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] know the state of an object
Tim Peters wrote: [dvd] ... So, in the end, I don't see any hope for you via this route, short of this: register an object as changed in your __setattr__ without worrying at all about _why_ __setattr__ was called. Later, when you do something with your list of modified objects, simply ignore any whose state at that time is UPTODATE. Those are exactly the objects whose state got materialized but didn't change thereafter. The long term solution to these are other related use cases is to start using events in ZODB. That is, ZODB should use zope.event to report happenings of potential interest to applications. Then applications can use the event system to be notified and provide additional functionality. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] know the state of an object
On Thu, 2005-10-13 at 19:04 -0400, Tim Peters wrote:
from the connection object,
You didn't say which version of ZODB you're using. Since you believe
a
Connection keeps track of which objects have been modified, I'll
assume
you're using ZODB 3.3 or later (which is either true, or your belief
about
who keeps track of modified objects is false ;-)).
yup i missed this info, i'm using zodb 3.4
so i overload the __setattr__ method in my base-class and keep track
of the modified objects
But that's the problem, __setattr__ is called also when ZODB loads
the
objects from the storage and reconstructs it, so is there a way to
know
the state of the object (unpickilng, modified, clean etc etc)?
The good news is that obj._p_state reveals the current state of a
persistent
object. The possible values are exposed by the `persistent` module:
I see, yesterday, after my message obviously, i see the light and write
this code
class PersistentObject(Persistent):
[... some code ...]
def __setattr__(self, attr, value):
if not self._p_setattr(attr, value):
super(PersistentObject, self).__setattr__(attr, value)
if not attr.startswith('_p_') and self._p_changed and attr!
='_Modified':
self.Touch()
So, in the end, I don't see any hope for you via this route, short of
this:
register an object as changed in your __setattr__ without worrying at
all
about _why_ __setattr__ was called. Later, when you do something
with
your list of modified objects, simply ignore any whose state at that
time is
UPTODATE. Those are exactly the objects whose state got materialized
but
didn't change thereafter.
Ok, thank you for your help
bye
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] know the state of an object
[Chris Withers, about getting at the collection of modified objects] How hard would it be to expose? The coding would be trivial in ZODB 3.6 (earliest version a new feature could land) if limited solely to Connection objects. More work to specify the interface and write tests. Would there be any performance implications? None from just from exposing the current Connection._registered_objects implementation detail via an official API. Whether that would be suitable for all intended purposes I don't know -- I haven't seen detailed use cases. Doubt it's a good idea regardless. As Jim wrote, things like this _should_ be approached not by adding an endless number of new APIs, but by introducing an event system. I don't know what the performance implications of that may be, since ZODB has nothing like it at present. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] know the state of an object
[dvd] this my first post to this list, and first of all thanks for your work. I'm developing a ZODB based Collection Management software, and, for a bunch of reasons, i have to know the list of modified objects before the current transaction commit. Looking around seems there is no a public API to obtains this list That's true. from the connection object, You didn't say which version of ZODB you're using. Since you believe a Connection keeps track of which objects have been modified, I'll assume you're using ZODB 3.3 or later (which is either true, or your belief about who keeps track of modified objects is false ;-)). so i overload the __setattr__ method in my base-class and keep track of the modified objects But that's the problem, __setattr__ is called also when ZODB loads the objects from the storage and reconstructs it, so is there a way to know the state of the object (unpickilng, modified, clean etc etc)? The good news is that obj._p_state reveals the current state of a persistent object. The possible values are exposed by the `persistent` module: import persistent persistent.GHOST -1 persistent.UPTODATE 0 persistent.CHANGED 1 persistent.STICKY 2 The possible state transitions are explained in persistent/interfaces.py, where UPTODATE is called saved. For reasons that escape me, it doesn't admit to the existence of _p_state (maybe that's not an official part of the API?). The bad news is that, during the transition from GHOST to UPTODATE (your ZODB loads the objects from the storage and reconstructs it), the state is temporarily set to CHANGED _before_ code is invoked to materialize the object's state (and is set to UPTODATE after that's done). This is to prevent runaway recursion, but no matter: while an object is being unghostified, it (untruthfully) claims to be in the CHANGED state, not the GHOST state you might expect. So, in the end, I don't see any hope for you via this route, short of this: register an object as changed in your __setattr__ without worrying at all about _why_ __setattr__ was called. Later, when you do something with your list of modified objects, simply ignore any whose state at that time is UPTODATE. Those are exactly the objects whose state got materialized but didn't change thereafter. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
