3:25 p.m.
The issue HSEARCH-1225 is about clarifying what is supposed to happen
when an entity type is having an EntityIndexingInterceptor registered
and the following method is called:
org.hibernate.search.FullTextSession.index(T)
Today, this method is ignoring the conditional indexing interceptor
altogether; this might be considered correct, but we should clarify it
as it brought some confusion.
As a reference this is the EntityIndexingInterceptor interface source code:
public interface EntityIndexingInterceptor<T> {
IndexingOverride onAdd(T entity);
IndexingOverride onUpdate(T entity);
IndexingOverride onDelete(T entity);
IndexingOverride onCollectionUpdate(T entity);
//FIXME should we add onPurge and onIndex?
}
My first idea about this was to clarify in documentation & javadoc
that the index() is going to ignore the interceptor. I thought that
would be a good idea so that users can have a method to override any
framework decision and force the write to be applied.
On the other hand, adding the methods mentioned in the FIXME would be
straight forward too, and while I'd expect most people to implement
onIndex() as return APPLY_DEFAULT, this might be a more elegant way
to:
- let the user choose about this
- make it very explicit what is going to happen
This looks like the best way to go, unfortunately it breaks backwards
compatibility but it was clearly marked as experimental in all media.
Thoughts?
#purgeAll
Of course the #purge method needs to be addressed in some consistent
way, but we can't implement it easily (and very slowly) on purgeAll.
One could redesign the MassIndexer pattern to be reused by a
mass-purger but I don't think it's worth it.
Cheers,
Sanne
2:57 a.m.
Hi,
I have always been of the opinion that FullTextSession#index should also apply the
interceptor.
At the very least there should be an easy way use the interceptor via the index API.
On 21 Jan 2012, at 10:25 PM, Sanne Grinovero wrote:
Today, this method is ignoring the conditional indexing interceptor
altogether; this might be considered correct, but we should clarify it
as it brought some confusion.
IMO it is wrong
My first idea about this was to clarify in documentation &
javadoc
that the index() is going to ignore the interceptor. I thought that
would be a good idea so that users can have a method to override any
framework decision and force the write to be applied.
There interceptors application should be the default with an explicit
option/api/configuration to
disable it.
On the other hand, adding the methods mentioned in the FIXME would
be
straight forward too, and while I'd expect most people to implement
onIndex() as return APPLY_DEFAULT, this might be a more elegant way
to:
- let the user choose about this
- make it very explicit what is going to happen
-1 I don't think this is the right place to do it. onAdd, OnUpdate, etc are on a
different architectural level
than index() and purge(). The latter actually create onAdd and onUpdate calls. It feels
messy to add
these methods to the interface.
Wy not add an #index(Object, boolean) to FullTextSession? The flag would indicate whether
interceptors should
be applied or not. #index(Object) would then be the default index operation with the flag
set to true or false, depending
what we think should be the default.
--Hardy
3:24 a.m.
Hi Hardy,
if we added such a method to the FulltextSession, how should it
invoke the interceptor?
Sanne
On 22 October 2012 08:57, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
Hi,
I have always been of the opinion that FullTextSession#index should also apply the
interceptor.
At the very least there should be an easy way use the interceptor via the index API.
On 21 Jan 2012, at 10:25 PM, Sanne Grinovero wrote:
> Today, this method is ignoring the conditional indexing interceptor
> altogether; this might be considered correct, but we should clarify it
> as it brought some confusion.
IMO it is wrong
> My first idea about this was to clarify in documentation & javadoc
> that the index() is going to ignore the interceptor. I thought that
> would be a good idea so that users can have a method to override any
> framework decision and force the write to be applied.
There interceptors application should be the default with an explicit
option/api/configuration to
disable it.
> On the other hand, adding the methods mentioned in the FIXME would be
> straight forward too, and while I'd expect most people to implement
> onIndex() as return APPLY_DEFAULT, this might be a more elegant way
> to:
> - let the user choose about this
> - make it very explicit what is going to happen
-1 I don't think this is the right place to do it. onAdd, OnUpdate, etc are on a
different architectural level
than index() and purge(). The latter actually create onAdd and onUpdate calls. It feels
messy to add
these methods to the interface.
Wy not add an #index(Object, boolean) to FullTextSession? The flag would indicate whether
interceptors should
be applied or not. #index(Object) would then be the default index operation with the flag
set to true or false, depending
what we think should be the default.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:26 a.m.
I haven't looked at this. I was just arguing form a user facing API and there I would
expect it the day I described. How we implement this is an internal thing.
--Hardy
On 22 Jan 2012, at 10:24 AM, Sanne Grinovero wrote:
Hi Hardy,
if we added such a method to the FulltextSession, how should it
invoke the interceptor?
Sanne
On 22 October 2012 08:57, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> Hi,
>
> I have always been of the opinion that FullTextSession#index should also apply the
interceptor.
> At the very least there should be an easy way use the interceptor via the index API.
>
> On 21 Jan 2012, at 10:25 PM, Sanne Grinovero wrote:
>
>> Today, this method is ignoring the conditional indexing interceptor
>> altogether; this might be considered correct, but we should clarify it
>> as it brought some confusion.
>
> IMO it is wrong
>
>> My first idea about this was to clarify in documentation & javadoc
>> that the index() is going to ignore the interceptor. I thought that
>> would be a good idea so that users can have a method to override any
>> framework decision and force the write to be applied.
>
> There interceptors application should be the default with an explicit
option/api/configuration to
> disable it.
>
>> On the other hand, adding the methods mentioned in the FIXME would be
>> straight forward too, and while I'd expect most people to implement
>> onIndex() as return APPLY_DEFAULT, this might be a more elegant way
>> to:
>> - let the user choose about this
>> - make it very explicit what is going to happen
>
> -1 I don't think this is the right place to do it. onAdd, OnUpdate, etc are on a
different architectural level
> than index() and purge(). The latter actually create onAdd and onUpdate calls. It
feels messy to add
> these methods to the interface.
>
> Wy not add an #index(Object, boolean) to FullTextSession? The flag would indicate
whether interceptors should
> be applied or not. #index(Object) would then be the default index operation with the
flag set to true or false, depending
> what we think should be the default.
>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:07 a.m.
As a user I need to implement the interceptor so to understand how to do
that I would need to know how such a method is going to interact with the
interceptor.
At the very least we need to define which of its method is going to be
invoked and I think both ADD and REMOVE are confusing, at least as defined
today. So before adding a new API we should define how it's going to work;
looks like you have a clear idea?
On Oct 22, 2012 9:26 AM, "Hardy Ferentschik" <hardy(a)hibernate.org> wrote:
I haven't looked at this. I was just arguing form a user facing
API and
there I would
expect it the day I described. How we implement this is an internal thing.
--Hardy
On 22 Jan 2012, at 10:24 AM, Sanne Grinovero wrote:
> Hi Hardy,
> if we added such a method to the FulltextSession, how should it
> invoke the interceptor?
>
> Sanne
>
> On 22 October 2012 08:57, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>> Hi,
>>
>> I have always been of the opinion that FullTextSession#index should
also apply the interceptor.
>> At the very least there should be an easy way use the interceptor via
the index API.
>>
>> On 21 Jan 2012, at 10:25 PM, Sanne Grinovero wrote:
>>
>>> Today, this method is ignoring the conditional indexing interceptor
>>> altogether; this might be considered correct, but we should clarify it
>>> as it brought some confusion.
>>
>> IMO it is wrong
>>
>>> My first idea about this was to clarify in documentation & javadoc
>>> that the index() is going to ignore the interceptor. I thought that
>>> would be a good idea so that users can have a method to override any
>>> framework decision and force the write to be applied.
>>
>> There interceptors application should be the default with an explicit
option/api/configuration to
>> disable it.
>>
>>> On the other hand, adding the methods mentioned in the FIXME would be
>>> straight forward too, and while I'd expect most people to implement
>>> onIndex() as return APPLY_DEFAULT, this might be a more elegant way
>>> to:
>>> - let the user choose about this
>>> - make it very explicit what is going to happen
>>
>> -1 I don't think this is the right place to do it. onAdd, OnUpdate, etc
are on a different architectural level
>> than index() and purge(). The latter actually create onAdd and onUpdate
calls. It feels messy to add
>> these methods to the interface.
>>
>> Wy not add an #index(Object, boolean) to FullTextSession? The flag
would indicate whether interceptors should
>> be applied or not. #index(Object) would then be the default index
operation with the flag set to true or false, depending
>> what we think should be the default.
>>
>> --Hardy
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4425
days inactive
4426
days old
4 comments
2 participants
participants (2)
-
Hardy Ferentschik -
Sanne Grinovero