[hibernate-dev] HSEARCH-1225

[Sanne Grinovero]

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