[hibernate-dev] Interceptor question
sanne at hibernate.org
Mon May 14 11:13:07 EDT 2012
On 14 May 2012 15:50, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On May 13, 2012, at 11:17 PM, Sanne Grinovero wrote:
>> I agree as a user it's not simple to deal with two "massindex"
>> approaches, even worse if they behave differently. Your
>> straight-forward take on it is to make sure they behave the same, and
>> I see some good value in it.. still we end up having two ways to
>> achieve the same thing, which is *one too much*. Let's go one step
>> further conceptually, and remove one (give me a second..).
> As Emmanuel is saying, the index API is not only an (old) alternative to
> the mass indexer. It stands in its own right.
Sorry I never meant to imply the opposite. I certainly do see it as
something that "stands on it's own right", I just don't see it as a
massindexer alternative since it can be used for very different
>> Proposal: after we clarify the fact that these methods go straight to
>> the index without any interception (no doubt clarification is needed),
>> we change the chapter describing the "old style indexing" from being
>> one of the suggested methods for reindexing, to be "just an example"
>> of the index method, and for example how it could be done to write
>> your own MassIndexer - however some wiring would be needed, for
>> example 1)the manual session clear and 2)apply indexing interceptors
>> are concerns the user has to take care of.
> I don't think that just cleaning up the documentation will be enough
>> +0,8 to optionally (with a boolean) enable interception on those
>> methods. I guess it might be handy, but I'm not fully convinced on
>> their use and it's yet-another-method, we're getting a bit complex.
>> At least it's better than always applying the interceptor as the
>> missing method would make it clear that this wouldn't work on
> An alternative to overloading these methods would be to add something like:
> void FullTextSession#enableInterceptors(boolean)
> boolean FullTextSession#areInterceptorsEnabled()
That's a very cool idea. What about
Just as I feel the need to point out what system it's related to,
since this interface exposes as well all ORM related methods.
> This way we can keep index(), purge() and purgeAll() intact and allow per full text
> session to change the behavior. IMO the default should be then to apply the interceptors.
> Adding these methods (as would the overloading approach) remove the black magic taste
> of the current approach.
>> #purgeAll: as Emmanuel pointed out that's not going to fly.
> Not sure why not
You might be right, if all what is indexed can always be nuked. Is
that always the case? Remember the implementation uses a single delete
statement on the index: all documents of class X are removed. It's
hard to express the user defined filter in those terms, unless we
extend the complexity of EntityIndexingInterceptor to rely on the user
to define this case.
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev