[hibernate-dev] Changing or deprecating @AnalyzerDef

[Sanne Grinovero]

On 3 March 2016 at 16:46, Emmanuel Bernard <emmanuel at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev