Re: [hibernate-dev] Changing or deprecating @AnalyzerDef
On 3 March 2016 at 16:46, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
They were intended to be there. Are they useful there is another
story
we can debate.
definitions can be defined on fields or methods. I could not find the
code that would isolate the definition between different fields but I
would have expected that intent. At any rate there is an explicit
handling of field / method analyzers.
Analyzer definitions are global to the SearchFactory; I don't remember
these ever having been scoped in the past?
We can deprecate that use if we think that clears the path.
Allowing them on a field obviously makes not much harm; I wouldn't
pursue any changes at all if it weren't for the idea of needing an
entirely new annotation to shield user code from Lucene classes (the
next point).
On Thu 2016-03-03 15:08, Sanne Grinovero wrote:
> I just realized that the definiton for @AnalyzerDef allows many target ypes:
>
> @Target({ ElementType.PACKAGE, ElementType.TYPE, ElementType.FIELD,
> ElementType.METHOD })
>
> I think FIELD and METHOD might not have been intended to be there.
>
> Should we correct this in 6 to
>
> @Target({ ElementType.PACKAGE, ElementType.TYPE })
>
> ?
>
> If so, since I don't see how to deprecate that I think we could start
> logging a warning now when we find one "misplaced".
>
> Alternatively we might want to fully deprecate this annotation, as it
> requires direct exposure to Lucene classes.
> I'm thinking we should at least change it to refer to FQCN of lucene
> classes rather than class instances, but maybe someone has even better
> ideas? (I don't like the typesafety of FQCN String names)
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev