What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)

[Jim Fulton]

A week or so ago, there was a thread on the distinction between
IObjectModifiedEvent, IObjectAnnotationsModifiedEvent, and
IObjectContentModifiedEvent.

I'd like to step back a little bit and brainstorm some use cases
that, hopefully, illustrate why we care about this.  Here's
a start:

- A persistence or versioning system wants to know when objects
   have changed so that they can save new versions of the object.

   This needs to be pretty much fool proof.  To do this, I think you
   really need to do something like what the ZODB persistence
   mechanism does. Perhaps for versions, once could hook into
   this mechanism somehow.

- Record, as meta data, the time that an object changes.
   My original thought was that this would track only
   data, not meta-data changes.  This is not what we are doing now.
   For example, updating an object's DC title changes it's modification
   time.

   I'm not sure what we should do here.

- Update indexes (and other cache-like data structures)

   There is a thought that perhaps the generated event could
   contain enough information to eliminate some indexes from
   use.  This is (mostly) an optimization.

   In one of his proposals, Uwe suggested including an
   interface and attributes that were changed as optional
   information in an event.  In some cases, I think this
   information could be pretty useful, however, it probably isn't
   useful in as many cases as you might expect. The common pattern
   for Zope 3 indexes is that they adapt an object to an interface
   of interest.  The index can't really know how an adapter
   computes it's data.  The data are sometimes computed from
   data in a completely separate interface.

   Probably the indexes that we *most* want to avoid reindexing are
   text indexes.  We have a ISearchableText interface that we
   commonly adapt objects to to get the text to index.  We really
   can't predict how this text is computed.

   A safer strategy seems to me to be to have the indexes themselves
   responsible for detecting changes that they care about.  I'm
   pretty sure that some of the Zope 2 indexes are careful to avoid
   reindexing, or at least avoid updating indexes if indexed values
   haven't changed.  Unfortunately, the Zope 3 indexes don't seem to
   be doing this fairly straightforward optimization, which is a
   shame.

Given the applications above, I don't think that there's value in
fine-grained modification events that justifies the complecity of
proposals we've thought of so far.

Thoughts?

Are there other applications for modification events that
I haven't considered?

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org