[hibernate-dev] Interceptor question

[Sanne Grinovero]

Right I didn't mean to imply that they are just "building blocks" for
a do-it-yourself massindexer, just that that example using the
scrollable resultset is an interesting example of how they can be
used.

So the essential question is, for people using index / purge /
purgeAll, to have *manual* control.. by *manual* do we intend that the
user as the last word, or should we still apply interceptors?

What I think is important is that, if we decide intereceptors are
applied, there is a way for the user to have the last word on what
should happen on the indexes.

Cheers,
Sanne

On 14 May 2012 09:06, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> To me index / purge / purgeAll are not simply about what the MassIndexer does.
> I can see use cases where you manually control indexing without considering
> doing this en mass. remember, people can disable event based indexing.
>
> On 13 mai 2012, at 23:17, Sanne Grinovero wrote:
>
>> [thread diverged, not sure how to reply on each point.. so clean sheet:]
>>
>> 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..).
>>
>> Second point is, with the exclusive indexing and the IndexManager
>> abstraction, it's pretty hard for the user to make "free form" changes
>> to the index: we don't allow external tools to connect to the index
>> and apply changes as we own the lock; the only option for the power
>> user is to use #index, #purge, #purgeAll to make "advanced" self
>> controlled changes to the index. This is the only option a user has to
>> override all the automagic behaviour, and let him deal with changes
>> directly. I think it's important that we have such an option to expose
>> the ultimate control toe the user overriding any internal filtering
>> logic, and these methods have always had this role.
>>
>> 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 think it's important to keep that example in the docs for those
>> cases there is a problem with the MassIndexer, or just as a great
>> example for those index controlling methods - but it's confusing to
>> suggest two ways to do the same thing as we do today.
>>
>> +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
>> #purgeAll: as Emmanuel pointed out that's not going to fly.
>>
>> Cheers,
>> Sanne
>