Re: [ZODB-Dev] Replacing bobobase_modification_time
Casey Duncan wrote:
I am posting this here to get reactions here for something that we have been discussing on zope-dev that pertains to the ZODB.
Dieter M. discovered that bobobase_modification_time (henceforth referred to as b_m_t) is not always an accurate representation of an object's modification time, especially when an object has been modified in a transaction that has not been commited. This is a problem when doing things like cataloging an object in the same transaction that it is modified.
I thought this issue created an opprotunity to solve two problems. The above problem and the anachronistic b_m_t API itself, which is always good for a laugh in Zope classes. The idea is to create a new method in PersistentExtra "getModificationTime" which returns the actual modification time of an object based on the time the change is registered if it has been changed and not commited and then the last commit time if no change has been made. I also propose we add a second method "getLastCommitTime" or some-such which behaves the same as the current b_m_t method. At the same time we would deprecate b_m_t.
Kapil Thangavelu prototyped a couple of ideas. I think his latest code is simple and straighforward enough to be incorporated, although it does not yet replace and deprecate b_m_t, which I think is important.
He posted sample code to zope-dev yesterday, here is a (rather long) link: http://zope.nipltd.com/public/lists/dev-archive.nsf/0a8715d5f3c7b6a3802568c1...
Thoughts anyone?
The basic problem is that b_m_t is a database modification time, not an application-meaningful time. You pointed out that there are application-meaningful times that are not captured by the database time. In addition, there are database modifications that are not meaningful to the application. Operations like export/import (copy/paste), version commit/abort, transactional undo, etc. cause the database times to change without making application-meaningful changes. Also, there could be state changes in an object that are not meaningful to the application. I think that a much better approach, if modification time is important to your application, is to store the application modification time in the object as a data attribute. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Tuesday 08 January 2002 09:15 am, Jim Fulton allegedly wrote:
The basic problem is that b_m_t is a database modification time, not an application-meaningful time. You pointed out that there are application-meaningful times that are not captured by the database time. In addition, there are database modifications that are not meaningful to the application. Operations like export/import (copy/paste), version commit/abort, transactional undo, etc. cause the database times to change without making application-meaningful changes.
Also, there could be state changes in an object that are not meaningful to the application.
I think that a much better approach, if modification time is important to your application, is to store the application modification time in the object as a data attribute.
Jim
Do you think then that it might be reasonable to include such a service in a higher level Zope base class? It seems to me that creation and mod time are basic services that are needed in many applications. I certainly agree with you as far as "database" vs. "application". It seems that it has been widely encouraged to use b_m_t for something that it was not designed for. Especially in light of the fact that it is a default index/metadata entry in ZCatalog. I think that developing an application-level service in Zope that behaves as people expect would prove extremely useful. On that note I think a problem with doing that is the inevitable namespace pollution that occurs when attributes are added widely to objects across the system. Has any thought been given to creating a better naming standard for attributes so that it is easier to avoid collisions? Perhaps something like the "_p_" and "_v_" prefixes used now? Or even just prefixing them with "zope" (for "Zope level" attrs). /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
I think that a much better approach, if modification time is important to your application, is to store the application modification time in the object as a data attribute.
It might be better to cause common Zope objects to do what Casey proposes (maybe via SimpleItem) as opposed to making folks keep app modtimes for those and as opposed to changing the semantics of bobobase_modification_time. In Zope2, this would be achieved via a mixin named something like Modifiable mixed in to DTML Document, File, etc. - C
On Tuesday 08 January 2002 06:47 am, Chris McDonough wrote:
I think that a much better approach, if modification time is important to your application, is to store the application modification time in the object as a data attribute.
It might be better to cause common Zope objects to do what Casey proposes (maybe via SimpleItem) as opposed to making folks keep app modtimes for those and as opposed to changing the semantics of bobobase_modification_time. In Zope2, this would be achieved via a mixin named something like Modifiable mixed in to DTML Document, File, etc.
this sounds like a much better approach to me. the only question i have then, is how to hook modification times (as opposed to storage timestamps) without messing with Transaction.py? cheers kapil
On Tuesday 08 January 2002 09:47 am, Chris McDonough allegedly wrote:
I think that a much better approach, if modification time is important to your application, is to store the application modification time in the object as a data attribute.
It might be better to cause common Zope objects to do what Casey proposes (maybe via SimpleItem) as opposed to making folks keep app modtimes for those and as opposed to changing the semantics of bobobase_modification_time. In Zope2, this would be achieved via a mixin named something like Modifiable mixed in to DTML Document, File, etc.
- C
That had been my original instinct, but I wasn't sure. It sounds like the best way to approach it. I think this is complex enough so that a formal (if short) fishbowl proposal is probably warranted to discuss whether it should be part of an existing mix-in or a new one. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/
In Zope2, this would be achieved via a mixin named something like Modifiable mixed in to DTML Document, File, etc.
- C
That had been my original instinct, but I wasn't sure. It sounds like the best way to approach it.
I think this is complex enough so that a formal (if short) fishbowl proposal is probably warranted to discuss whether it should be part of an existing mix-in or a new one.
I agree - it also needs to pay special attention to describing the expected behavior, as it won't be easy to deal with existing objects without relying on b_m_t in some way. Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com
participants (5)
-
Brian Lloyd -
Casey Duncan -
Chris McDonough -
Jim Fulton -
kapil thangavelu