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(a)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