[Grok-dev] Re: Keeping indexes up to date
faassen at startifact.com
Fri Aug 10 11:07:05 EDT 2007
Philipp von Weitershausen wrote:
> On 10 Aug 2007, at 13:35 , Luciano Ramalho wrote:
>> On 8/10/07, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
>>> Note that the two container events, IObjectAddedEvent and
>>> IObjectRemovedEvent, are already sent by container operations and
>>> needn't be sent by you.
>> The fact that those were already taken care of tripped me.
> Well, there's a reason for that. When you add an object to a container,
> the container sets __parent__ and __name__ on that object. Not you, the
> container. That's why the container is responsible for sending the
> event, not you.
>> If a object is smart enough to know when it was changed for the sake
>> of persistency, shoudn't it fire IObjectModifiedEvents as well?
> First of all, objects are *not* smart. They're really really dumb. They
> should have as little functionality as possible. They're just data bags.
I don't consider the ability to send "I have changed" automatically as
> This data may be persisted by the ZODB and the ZODB may have ways to
> find out which attributes changed, but this is rarely enough information
> for an IObjectModifiedEvent (remember, this event contains information
> about which fields of which schema were changed).
IObjectModifiedEvent doesn't have to contain this information, right?
The minimum case is just to say the object changed, and that's it.
> Also, what do you about objects that aren't persisted in the ZODB?
That could still be the responsibility of the application developer
and/or the persistence layer developer.
That said, IObjectModifiedEvent may sometimes need to be sent even if
the object itself has not changed. This may for instance be the case if
something is indexed that is calculated *by* the object but not stored
*in* the object. This is a fairly rare case, however and could still be
I think asking "why don't ObjectModifiedEvents get sent by the
persistence layer where possible?" is a good question and we should
ponder it a little bit more. I wonder especially whether we could enable
this on a per-class basis, which should block some of the worries we
might have in it sending these events over-eagerly.
I don't know what the technical issues are against having the
persistence layer send object modified events. Perhaps the ZODB is only
able to detect such changes too late, causing more changes while a
commit is already taking place. I don't know enough about the details to
know whether this is true, however, and whether this would be a
More information about the Grok-dev