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

[Uwe Oestermeier]

jim at zope.com wrote:
>
>- 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.

Yes, that's an alternative I'm considering. It would be nice to have an
explict API for getting the modified objects of a transaction and I
remember that this was discussed on another list months ago. Is there such
an API already? I didn't find one.
>
>- 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.

In my view this depends on the use case. For instance, currently I'm
working on a blog system that uses DC title and description together with
the body of the blog entry as parts of  a searchable text. The whole blog
entry with title, description, and body appears to the user as a unit. In
this case it seems ok, that the modification date is changed if one part
of the searchable text is changed. But I'm also using DC effective as
publication date and there it would be misleading if a change of the
publication date also changes the modification date. So we have at least
two types of annotations here. This was one reason, why I proposed a
pluggable mechanism for event notification. We cannot know in advance what
kinds of events are really needed and which distinctions will be necessary
in the future. But I agree with you, that the use of a utility is not very
Pythonic, although the proposed modify(obj, key1=value1,  key2=value2,
...) syntax was borrowed from dict.update.
>
>- 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.

...
>
>   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.

Yes, not from outside. But as a programmer I know which interfaces I use.
To use the blog example again: given that the used interface+attribute is
recorded in the modification event it's not to difficult to write a
subscriber that listens to changes of the body, the title or description,
and fires an additional modification event for
ISearchableText["getSearchableText"] if a change of a part is detected.
The problem of computed attributes has to be solved anyway. If I have an
object schema that promises an attribute and the value is computed from
the state of other objects we have chains of dependent modification
events, or we cannot rely on the event mechanism any longer. It is
probably easier to write and understand such chains if the events describe
in detail what happens.
>
>
>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.

That might be, but what remains from the idea of loosely connected
components that communicate via events if we need hooks into the
transaction machinery for versioning, a special dependency checker for
indexing and caching, and application specific modification events even
for a simple blog implementation?
>
>
>Thoughts?

The container events are much more specific and contain enough information
to undo/redo the described operation. Why are modification events treated
differently here? Wouldn't it be a usefull rule of thumb, that all events
should carry enough information to be able to undo/redo them?

I agree with Dieter that efficiency will become important as soon as Zope3
has to cope with office documents and user expectations. I'm not sure
whether all optimization issues should be left to the applications. This
will result in applications that use hooks, direct update calls, etc.
instead of events and it will become difficult to use them in combination.
>
>Are there other applications for modification events that
>I haven't considered?

I'm using modification events in a wxPython app with a MVC architecture.
Zope3 events are a very clean way to keep models and their views in sync.
There are of course other ways to avoid unnecessary flicker, but the most
easy way to update only the affected parts of a view is to specify the
changed part of the  model. That was also a motivation behind my proposal
to use a pluggable modification mechanism.


-- Uwe


>
>