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 \---------------------------------------------------/