[Zope-CMF] Re: Don't always set the modification date?

[Florent Guillaume]

Paul Winkler  <pw_lists at slinkp.com> wrote:
> On Sun, Feb 13, 2005 at 07:05:32PM +0100, yuppie wrote:
> > 1.) Updating 'modification date' or not is policy and should be 
> > customizable.
> 
> That's where I'm coming from.
>  
> > 2.) editMetadata() and edit() call reindexObject(). If you use 
> > setModificationDate() *after* editMetadata() you have to make sure the 
> > catalog is up to date.
> 
> Doh! Thanks for the heads-up.
>  
> > 3.) For historical reasons reindexObject() calls notifyModified(), not 
> > the other way round. 
> 
> Are the reasons anything other than historical?
> That feels wrong. Would changing it break any known applications?

Yes.
Historically the modification date was returned using just
bobobase_modification_date. Obviously we wanted something more flexible
so I added an explicit modification_date attribute. But it had to be
updated, and there are hundreds of products out there that we didn't
want to change, so I piggybacked on reindexObject and decided to call
notifyModified() when a simple reindexObject() without arguments was
called. That fits the bill pretty well.

> > So calling reindexObject() after 
> > setModificationDate() sets a new timestamp.
> 
> GAH!
> 
> > Calling 
> > reindexObject(idxs=['modified']) preserves the timestamp and updates the 
> > index,

That's the better way to do it I think.

> but doesn't update the brain / metadata in the catalog.

That one is really a bug in ZCatalog. :-( I can't find a report about
it, but I thought I saw patches floating around to fix this.

> > Occasionally I use this workaround:
> > 
> >     obj.reindexObject(idxs=['suppress_notifyModified'])

That's a working workaround yes.

> > Of course that's expensive and just a hack.
> > 
> > 4.) CMF 1.5 has the same issues with 'creators'.
> > 
> > 5.) If CMFEvent will become reality cleaning up that mess should be easier.
> 
> Yeah. As time goes on, I find more and more cases where the lack of
> events is really becoming a hindrance for me.

Events are really a necessity. I'm glad my framework has them, I
couldn't live without them.

Florent

> E.g. I often end up monkey-patching manage_afterAdd and friends
> because there's no other obvious place to hook into 
> objects being moved.


-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com