Re: [Zope] [Bug] "bobobase_modification_time" unreliable to catalog
This behavior is logical if unintuitive. I propose that we can kill two birds with one stone to fix this: - Add a new method perhaps: getModificationTime() to the API of SimpleItem or even Persistent that returns the ZODB modification time or if the object has been changed, but not yet commited, the current date/time. - Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3. This will fix the aforementioned bug and get rid of an API anachronism. Thoughts? -Casey --- Dieter Maurer <dieter@handshake.de> wrote:
I just discovered that the value cataloged for "bobobase_modification_time" is often wrong:
The cataloged value is not the time of the current modification but that of the previous modification.
I expect that this is because "bobobase_modification_time" is updated when the transaction is commited while the values to be cataloged are determined before the commit.
Do not trust the cataloged "bobobase_modification_time"!
Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
__________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
Casey Duncan wrote:
- Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3.
This will fix the aforementioned bug and get rid of an API anachronism.
Awww... but we'll loose one of the more amusing prefixes in Zope parlance ;-) cheers, Chris (that'll be a big +1 from me :-)
On Sunday 30 December 2001 08:00 pm, Casey Duncan wrote:
This behavior is logical if unintuitive. I propose that we can kill two birds with one stone to fix this:
- Add a new method perhaps: getModificationTime() to the API of SimpleItem or even Persistent that returns the ZODB modification time or if the object has been changed, but not yet commited, the current date/time.
- Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3.
This will fix the aforementioned bug and get rid of an API anachronism.
Thoughts?
sounds good, i played around with an implementation to do the above. i'm not posting it here causes its inefficient, although i'm happy to email it to anyone who's interested. it basically added three methods. 1. getModificationTime to App/PersistinentExtra.py 2. is_registered(self,object) to ZODB/Transaction.py 3. get_registration_time(self, object) to ZODB/Transaction.py add one data structure to Transaction.py, a registration_times dict. when objects are registered they get a DateTime registered with them that gets added to registration_times based on their position within the registered objects list (_objects). another solution might be a weak ref. keyed dict. so getModificationTime checks if the object is registered in the current transaction if it is it calls get_registration_time, else it falls through to bobobase_modification_time. there are two inefficiencies one is memory because of DateTime for every registered object and two is computational from the lack of a uniform (across subclasses) hash function for persistent objects which results in traversal of the registered object list to identify if an object is registered or not (and to determine position to figure out the index into registration_times). a much better solution memory wise would have the transaction.py keep a DateTime for its initialization and then have registered objects store registration times as deltas of that. i'm not sure what the better solution is in terms of the computational issue. but as is this solution doesn't seem scalable to me until the computational issues can be handled. cheers kapil
-Casey
--- Dieter Maurer <dieter@handshake.de> wrote:
I just discovered that the value cataloged for "bobobase_modification_time" is often wrong:
The cataloged value is not the time of the current modification but that of the previous modification.
I expect that this is because "bobobase_modification_time" is updated when the transaction is commited while the values to be cataloged are determined before the commit.
Do not trust the cataloged "bobobase_modification_time"!
Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
__________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Saturday 05 January 2002 08:15 pm, kapil thangavelu allegedly wrote:
On Sunday 30 December 2001 08:00 pm, Casey Duncan wrote:
This behavior is logical if unintuitive. I propose that we can kill two birds with one stone to fix this:
- Add a new method perhaps: getModificationTime() to the API of SimpleItem or even Persistent that returns the ZODB modification time or if the object has been changed, but not yet commited, the current date/time.
- Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3.
This will fix the aforementioned bug and get rid of an API anachronism.
Thoughts?
sounds good, i played around with an implementation to do the above. i'm not posting it here causes its inefficient, although i'm happy to email it to anyone who's interested. it basically added three methods.
[snip details]
there are two inefficiencies one is memory because of DateTime for every registered object and two is computational from the lack of a uniform (across subclasses) hash function for persistent objects which results in traversal of the registered object list to identify if an object is registered or not (and to determine position to figure out the index into registration_times). a much better solution memory wise would have the transaction.py keep a DateTime for its initialization and then have registered objects store registration times as deltas of that. i'm not sure what the better solution is in terms of the computational issue. but as is this solution doesn't seem scalable to me until the computational issues can be handled.
For memory concerns, couldn't you just store the DateTime as a floating point number? This would incur just a small overhead to create a DateTime object when the value is looked up. I am interested in seeing this code. From my perspective it seems overly sophisticated. I'm interested how you derive the registration time in the first place. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
On Monday 07 January 2002 06:20 am, Casey Duncan wrote:
On Saturday 05 January 2002 08:15 pm, kapil thangavelu allegedly wrote:
On Sunday 30 December 2001 08:00 pm, Casey Duncan wrote:
This behavior is logical if unintuitive. I propose that we can kill two birds with one stone to fix this:
- Add a new method perhaps: getModificationTime() to the API of SimpleItem or even Persistent that returns the ZODB modification time or if the object has been changed, but not yet commited, the current date/time.
- Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3.
This will fix the aforementioned bug and get rid of an API anachronism.
Thoughts?
sounds good, i played around with an implementation to do the above. i'm not posting it here causes its inefficient, although i'm happy to email it to anyone who's interested. it basically added three methods.
[snip details]
For memory concerns, couldn't you just store the DateTime as a floating point number? This would incur just a small overhead to create a DateTime object when the value is looked up.
I am interested in seeing this code. From my perspective it seems overly sophisticated. I'm interested how you derive the registration time in the first place.
your right, what i did was overly complex. i took your suggestions and simplified to the following two methods, which stores the txn registration time on the object as a float. it looks like an ok solution, imo. it doesn't do much for newly created persistent objects for which it falls through to the behavior of bobobase_modification_time and returns the current time. in PersistentUtil class in lib/python/App/PersistentExtra.py new method from Acquisition import aq_base def getModificationTime(self): ob = aq_base(self) if hasattr(ob, '_p_changed') and ob._p_changed: return DateTime(self._p_registration_time) else: return self.bobobase_modification_time() in Transaction class in lib/python/ZODB/Transaction.py altered register method def register(self, object): self._append(object) object._p_registration_time = time.time() cheers kapil
On Monday 07 January 2002 07:38 am, kapil thangavelu allegedly wrote:
On Monday 07 January 2002 06:20 am, Casey Duncan wrote: [snippingtons]
I am interested in seeing this code. From my perspective it seems overly sophisticated. I'm interested how you derive the registration time in the first place.
your right, what i did was overly complex. i took your suggestions and simplified to the following two methods, which stores the txn registration time on the object as a float. it looks like an ok solution, imo. it doesn't do much for newly created persistent objects for which it falls through to the behavior of bobobase_modification_time and returns the current time.
in PersistentUtil class in lib/python/App/PersistentExtra.py new method
from Acquisition import aq_base def getModificationTime(self): ob = aq_base(self) if hasattr(ob, '_p_changed') and ob._p_changed: return DateTime(self._p_registration_time) else: return self.bobobase_modification_time()
in Transaction class in lib/python/ZODB/Transaction.py altered register method
def register(self, object): self._append(object) object._p_registration_time = time.time()
That looks nice and simple to me. Does anyone have a concern about the behavior for new objects? (I'm not sure what can be done about it...) If no one objects I can check this into the core. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
That looks nice and simple to me. Does anyone have a concern about the behavior for new objects? (I'm not sure what can be done about it...)
If no one objects I can check this into the core.
Or before getting ahead of myself, does this still need a proposal and all that? /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
That looks nice and simple to me. Does anyone have a concern about the behavior for new objects? (I'm not sure what can be done about it...)
If no one objects I can check this into the core.
Or before getting ahead of myself, does this still need a proposal and all that?
I'm ok with the change, so long as: - the folks on zodb-dev are notified and think its OK - someone takes a look at the API docs in the Zope book to decide what this affects and sends me the changes and updates to relay to Amos ...before anything is committed. After it is committed, the committer needs to coordinate with the ZODB-dev guys to make sure it percolates into StandaloneZODB, etc. Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com
participants (5)
-
Brian Lloyd -
Casey Duncan -
Casey Duncan -
Chris Withers -
kapil thangavelu