Jim Fulton wrote at 2005-5-27 08:29 -0400:
> ...
>> Then, we probably do something wrong...
>That's always a possibility.  I think what we are doing is
>pretty reasonable.  Perhaps you have other suggestions.

I think we need more control over what modifications trigger
what reindexing events.

I am not yet sure about the best (or even a good) approach.

>> Even computing the value for a text index (without any change
>> to the index itself) can be very expensive: it may
>> include expensive fetching of a large object,
>> an expensive conversion (text extraction), expensive splitting
>> and comparison to what is currently indexes.
>Perhaps. It depends a lot on the application.
>I suggest that, if this optimization is important, it might
>be much easier and cleaner to make text extracttion and comparison
>cheap, rather than, trying to solve the problem with a more complex
>event model.

You cannot make text extraction cheap (as it handles potentially large

You could make comparison cheap -- e.g. by storing last modification
dates and comparing them.
But, I fear, you would just move the problem to when changing the
modification date.

> ...
>I think it would be very difficult to come up with rules
>for deciding which events might effect a text value and which would not.
>For example, I can easily imagine objects who's searchable text
>depends on their workflow state.

Indeed, such objects are easily imaginable.
But usually, it is not the case.

The problem is obviously difficult -- not solvable with
a trivial event model and trivial reindexing dispatching.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to