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

[Philipp von Weitershausen]

Martijn Faassen wrote:
> 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.

Maybe it's not *very* intelligent, but I consider the awareness of any 
event framework whatsoever as a definite step away from the "dumb data 
storage philosophy".

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

This is a matter of intepretation. I think it should always contain this 
information, especially if you can actually easily determine what 
changed exactly. zope.formlib and zope.app.form unfortunately don't do 
this. I've filed a bug report, but haven't done anything about it yet. 
At least I've made sure grok.formlib sends all the information.

> The minimum case is just to say the object changed, and that's it.

Yes, but there are lots of ways an object can change. Indexing can 
likely be an expensive operation (e.g. indexing lots of text in a 
unicode attribute), so it would make sense to have this extra 
information so that expensive stuff can be skipped.

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

IObjectModifiedEvent is also supposed to be sent when you change an 
object's annotations. More specifically, you're can (and are supposed 
to) send a modified event when you haven't changed any of the object's 
own attributes but fields that the object doesn't even provide itself, 
only through an adapter. An example from my book::

   dc = IZopeDublinCore(recipe)
   dc.title = recipe.name

   info = Attributes(IZopeDublinCore, 'title')
   notify(ObjectModifiedEvent(recipe, info))

Note that the event is sent for the "recipe" object (not for "dc").

Why is this necessary? Because indexes can adapt an object to an 
arbitrary interface (e.g. IZopeDublinCore) and index the adapter's 
attribute.

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

We should certainly document it clearly that ZODB persistence gives you 
a lot of transparency, but not that kind of transparency with the event 
framework and the indexing machinery.

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

Theuni might be able to comment here.


-- 
http://worldcookery.com -- Professional Zope documentation and training