1:22 p.m.
The reason I did map manual indexing to apply default is that I sided with Sanne s
reasoning and I went on the side of caution with the API. I'd love to get more
practical feedback before deciding to either:
- stay as it is
- map indexing and purge to the interceptor - I don't think we can safely map purge
all
- add two methods to the interceptor to treat index and purge explicitly
Emmanuel
On 11 mai 2012, at 17:45, Hardy Ferentschik <hardy(a)ferentschik.de> wrote:
Really? I would argue differently.
Let's take the blog example where I only want to index blog entries which are
published. Adding the interceptor and relying on automatic indexing will not index
un-published entries. Great.
If I, however, want/ have to re-index my blog entries via the API the interceptor does
not apply? Why?
IMO the interceptor has to apply for automatic index updates as well as explicit index
request. Conceptually
(for a user) there is no difference between explicitly calling FulltextSession#index or
auto-indexing. That's
exactly the type of confusion the user on the forum experienced.
I think we should change this behavior.
--Hardy
On May 11, 2012, at 5:23 PM, Sanne Grinovero wrote:
> As a user if I were asking to Search *explicitly* to index my entity,
> I would not be pleased in the framework to override my request... I
> think the code is correct, maybe it's worth pointing this out at least
> on #index() javadoc?
>
> Sanne
>
> On 11 May 2012 14:48, Hardy Ferentschik <hardy(a)ferentschik.de> wrote:
>> Hi,
>>
>> quick question regarding the indexing interceptor. Why is WorkType.Index mapped
to IndexingOverride.APPLY_DEFAULT -
>>
https://github.com/hferentschik/hibernate-search/blob/master/hibernate-se...
>>
>> Shouldn't it be the same as ADD? Am I missing something? I am asking, because
of https://forum.hibernate.org/viewtopic.php?f=9&t=1015173
>>
>> --Hardy
3:01 a.m.
New subject: Interceptor question
On May 11, 2012, at 20:22, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
The reason I did map manual indexing to apply default is that I sided
with Sanne s reasoning and I went on the side of caution with the API. I'd love to get
more practical feedback before deciding to either:
- stay as it is
- map indexing and purge to the interceptor - I don't think we can safely map purge
all
+1
- add two methods to the interceptor to treat index and purge
explicitly
Another alternative would be to add new #index and #purge methods which for example take
an additional Boolean flag for whether interceptors should be applied or not. We can then
decide what the default behavior is for the existing index/purge operations.
--hardy
4:17 p.m.
New subject: Interceptor question
[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
3:06 a.m.
New subject: Interceptor question
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
9:22 a.m.
New subject: Interceptor question
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
9:36 a.m.
New subject: Interceptor question
On May 14, 2012, at 4:22 PM, Sanne Grinovero wrote:
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?
How does the her not have the last word if we apply the interceptor?
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.
He has full control over the interceptor implementation!
--Hardy
9:50 a.m.
New subject: Interceptor question
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
10:13 a.m.
New subject: Interceptor question
On 14 May 2012 15:50, Hardy Ferentschik <hardy(a)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
purposes.
> 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
FullTextSession#enableIndexingInterceptors(boolean) ?
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.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:22 a.m.
New subject: Interceptor question
>> +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
FullTextSession#enableIndexingInterceptors(boolean) ?
Sure, that's how it should be called in the end.
The thing I like about this solution is also that it is inline with how we do similar
things
in (Fulltext)Session.
>> #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.
fair point
--Hardy
4613
days inactive
4616
days old
8 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero