[Zope-dev] Re: [Zope] [Bug] "bobobase_modification_time" unreliable to catalog

[kapil thangavelu]

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 )