A week or so ago, there was a thread on the distinction between
IObjectModifiedEvent, IObjectAnnotationsModifiedEvent, and
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 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
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
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.
Are there other applications for modification events that
I haven't considered?
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list