Note that in most projects, people now deal with an explicit 'modication_date' or 'modification' property like you suggested. But this requires setting it whenever the object changes. Florent On Sat, 2002-06-29 at 19:22, Carl Rendell wrote:

Thanks Florent,

On Saturday, June 29, 2002, at 09:51 AM, Florent Guillaume wrote:

...

[Redirecting to zope-dev]

Carl Rendell <cer@sol43.com> wrote:

...

Has anyone on the list ever 'set' the modification or other date attributes on an object in the ZODB? I've looked at the bobobase_modification_time() call and found it looks at an attribute [_p_mtime] for an object, but have yet to discover what controls the setting of that attribute, or if that is the attribute to set?

I'm familiar with changing these on items in a file system, but performing the same task on an object in the ZODB has me stumped right now.

I looked a few weeks ago, and it's deep in the C code, and grep-proof besides :-) Look in ZODB/cPersistence.c, grep for "'m'" (with single quotes).

I was looking in to that section, an others in the ZODB area. I've been playing with trying to set the '_p_mtime' attribute directly via - setattr(obj,'_p_mtime',time) - but that does not work.

...

My conclusion was that it was very tied to the ZODB and that setting it would probably break the serial or transaction mechanisms.

More than likely your on the money. It's a problem when I'm in a situation where I want to update a number of objects in the ZODB, say to add some attributes or properties, but don't want to change the last modification date. There are other 'indirect' implementations - adding a 'modification' property for example - but they are messy.

The other issue I'd like to tackle with this moving contents from a file system into zope. Ideally the date information once in Zope is the same as that in the file system - i'm thinking about ISO 9000 documentation for example where these dates are really important.

I'll keep digging and see what the list turns up. More than likely you are right, and the date information is too deep to get at through scripting.

-- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com