5:54 p.m.
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
6:07 p.m.
New subject: Interceptor question
I was expecting you to argue about it, and therefore I concede that
some docs clarification at least is strongly required, but I disagree
on the expectations:
I see a fundamental difference in behaviour expectations between
a) "sync up database and index"
b) "index Entries A and B now"
In the first case it's up to Search to figure out what the correct set
of data is, and this would obviously be defined by the conventional
rules such as "all what's in the database", and implicitly by the
filter.
In the second case the user is explicitly demanding to index A and B;
just think about the meaning of using #index .. it should never be
needed if everything was perfectly in sync, so the intention of the
method is clearly an explicit override.
Makes sense? Why would anyone use #index BTW ?
Sanne
On 11 May 2012 16:54, Hardy Ferentschik <hardy(a)hibernate.org> 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
6:15 p.m.
New subject: Interceptor question
On May 11, 2012, at 6:07 PM, Sanne Grinovero wrote:
I was expecting you to argue about it,
:-)
and therefore I concede that
some docs clarification at least is strongly required,
at the very least
but I disagree on the expectations:
I see a fundamental difference in behaviour expectations between
a) "sync up database and index"
b) "index Entries A and B now"
In the first case it's up to Search to figure out what the correct set
of data is, and this would obviously be defined by the conventional
rules such as "all what's in the database", and implicitly by the
filter.
In the second case the user is explicitly demanding to index A and B;
just think about the meaning of using #index .. it should never be
needed if everything was perfectly in sync, so the intention of the
method is clearly an explicit override.
It is needed (unless you use the mass indexer) to build an initial index or
rebuild an existing one. Also if I call #index I say "index this entity considering
all the configuration which exists for this entity" (meaning the defined fields, but
also defined interceptors). How else can I rebuild the index for the blog example?
Makes sense?
No
Why would anyone use #index BTW ?
Fair point. However, atm we still offer both alternatives (mass indexer and explicit
#index)
and I would argue they should behave the same way. See section 6.3. Rebuilding the whole
index
in the docs.
--Hardy
Sanne
On 11 May 2012 16:54, Hardy Ferentschik <hardy(a)hibernate.org> 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
>
6:34 p.m.
New subject: Interceptor question
On 11 May 2012 17:15, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On May 11, 2012, at 6:07 PM, Sanne Grinovero wrote:
> I was expecting you to argue about it,
:-)
> and therefore I concede that
> some docs clarification at least is strongly required,
at the very least
no doubt
> but I disagree on the expectations:
>
> I see a fundamental difference in behaviour expectations between
> a) "sync up database and index"
> b) "index Entries A and B now"
>
> In the first case it's up to Search to figure out what the correct set
> of data is, and this would obviously be defined by the conventional
> rules such as "all what's in the database", and implicitly by the
> filter.
>
> In the second case the user is explicitly demanding to index A and B;
> just think about the meaning of using #index .. it should never be
> needed if everything was perfectly in sync, so the intention of the
> method is clearly an explicit override.
It is needed (unless you use the mass indexer) to build an initial index or
rebuild an existing one. Also if I call #index I say "index this entity considering
all the configuration which exists for this entity" (meaning the defined fields,
but
also defined interceptors). How else can I rebuild the index for the blog example?
Since the filter is user defined, based on the fact that the user
*knows* the blog needs to be indexed only when [businessrule],
it's not hard to adapt the code using an
if [businessrule] {
fulltextSession#index( e );
}
else {
log.discardBlogDRAFTFromIndex( e );
}
> Makes sense?
No
> Why would anyone use #index BTW ?
Fair point. However, atm we still offer both alternatives (mass indexer and explicit
#index)
and I would argue they should behave the same way. See section 6.3. Rebuilding the whole
index
in the docs.
Maybe we shouldn't imply they are the same. Obviously the "old style"
provides far more control, this is just showcasing once more the
additional control the user has.
Let's put it the other way around: you want to use #purge( A ).
Why would you use the method? I guess because you want to remove
something from the index. And you want it to happen *now*, not start
to argue with the system ..
Would you expect Search to prevent you from doing that if the indexing
policy doesn't agree? And should it happen silently, or would you
expect an exception like
throw new SearchException( " HAHA we won't allow you to remove that!
No way! Go do your homework and implement a better filter strategy, or
go edit the index with an hex editor. No way we help you out!" )
;-)
Sanne
--Hardy
>
> Sanne
>
> On 11 May 2012 16:54, Hardy Ferentschik <hardy(a)hibernate.org> 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
>>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:58 a.m.
New subject: Interceptor question
Since the filter is user defined, based on the fact that the user
*knows* the blog needs to be indexed only when [businessrule],
it's not hard to adapt the code using an
if [businessrule] {
fulltextSession#index( e );
}
else {
log.discardBlogDRAFTFromIndex( e );
}
Not hard, but not expected. If I were a user I would wonder why I have to jump through
these hoops, even though I just configured an interceptor. Even worth, it is not
documented and even worse the mass indexer suddenly applies it.
Maybe we shouldn't imply they are the same. Obviously the
"old style"
provides far more control, this is just showcasing once more the
additional control the user has.
Why not? Why making it even harder for users. Yet another little detail to keep in mind.
Why not keeping it simple?
Let's put it the other way around: you want to use #purge( A ).
Why would you use the method? I guess because you want to remove
something from the index. And you want it to happen *now*, not start
to argue with the system ..
I was wondering about this as well and initially I thought ,hey maybe purging is different
and one has to behave differently. However, thinking more about it, I think the
interceptor should be even applied there. First I argue that not many users will have a
need to change the delete/purge operation. BUT if they do, they might have a reason, so it
makes only sense to not delete the entity on purge either.
Bottom line is that applying the interceptors consistently harbors much less surprises for
the user and gives him a much simpler model of "how Search works". A user who
does not know the intrinsic implementation details will always create some sort of model
how he thinks the frameworks works. Why confusing the user with different behavior between
automatic indexing, index API and mass indexer. Conceptually they should all do thing.
Would you expect Search to prevent you from doing that if the
indexing
policy doesn't agree? And should it happen silently, or would you
expect an exception like
throw new SearchException( " HAHA we won't allow you to remove that!
No way! Go do your homework and implement a better filter strategy, or
go edit the index with an hex editor. No way we help you out!" )
What are you trying to do here? The user has written and configured the interceptor, so it
he wants to prevent deletion, so be it. And yes, if push comes to shove he will have to
delete the index manually.
--hardy
4633
days inactive
4634
days old
4 comments
2 participants
participants (2)
-
Hardy Ferentschik -
Sanne Grinovero