[Grok-dev] Re: Keeping indexes up to date

[Martijn Faassen]

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

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

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

Regards,

Martijn