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.
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()
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
--Hardy