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 <emman...@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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
