[JBoss JIRA] (ISPN-11795) Entity mapping deprecations
by Yoann Rodière (Jira)
[ https://issues.redhat.com/browse/ISPN-11795?page=com.atlassian.jira.plugi... ]
Yoann Rodière commented on ISPN-11795:
--------------------------------------
A bit more details in case you need it (some of which we hadn't time to mention during our meeting).
h3. Custom FieldBridges
New APIs have been introduced in Search 6, but those new APIs are completely generic and do not expose anything related to Lucene, on contrary to the old FieldBridge APIs. So they are inherently incompatible.
The only Search 5 field bridges we *may* be able to support one day with a backward compatibility layer are the ones implementing {{StringBridge}} and {{TwoWayStringBridge}}. {{FieldBridge}}, {{TwoWayFieldBridge}}, {{ParameterizedBridge}}, {{IgnoreAnalyzerBridge}}, {{EncodingBridge}} are unlikely to be supported through a compatibility layer and will have to be rewritten entirely using the new Search 6 API.
h3. {{@AnalyzerDef}}
{{@AnalyzerDef}} and {{@NormalizerDef}} annotations will be gone in Search 6. The only way to define analyzers/normalizers will be through a custom component. The corresponding interface is {{org.hibernate.search.analyzer.definition.LuceneAnalysisDefinitionProvider}} in Search 5. In Search 6 it's another interface, but one that is very similar in how it works: {{org.hibernate.search.backend.lucene.analysis.LuceneAnalysisConfigurer}}.
h3. Index time boost
We're talking about {{(a)Field.boost}}. It's been deprecated some time ago in Lucene and Hibernate Search. Newer versions of Lucene don't allow index-time boosting (at least not easily). Query-time boosting should be used instead.
h3. Analyzer discriminator
{{@AnalyzerDiscriminator}} mixes the "entity" world and the "document" world; as a result it does not fit very well Search 6's architecture, and also can't be supported in Elasticsearch. That's why it was removed with no replacement.
There are alternatives in Search 6, however; see https://hibernate.atlassian.net/browse/HSEARCH-3311 for a design that could replace analyzer discriminators, and can be implemented on the user side.
h3. Default analyzer
In Search 5:
* You can define a global default analyzer through the configuration property {{hibernate.search.analyzer}}
* You can define a default analyzer for a given type through the annnotation {{@Analyzer}} on the type.
These options are gone in Hibernate Search 6; whenever you define a full-text field, you must use the {{@FullTextField}} annotation and you must pass an analyzer name to {{(a)FullTextField.analyzer}}. Hibernate Search 6 won't "cascade" to the type or to the global scope to find a default analyzer.
h3. Default indexNullAs
There is a special value for {{(a)Field.indexNullAs}} in Search 5 defined in {{org.hibernate.search.annotations.Field#DEFAULT_NULL_TOKEN}}. When this value is set, Search 5 will try to parse whatever null token was configured in the configuration property {{hibernate.search.default_null_token}}, and use that as a null token.
Since such a global default obviously cannot be parsed into *all* field types (string, integer, enum, ...), it was removed in Search 6.
> Entity mapping deprecations
> ---------------------------
>
> Key: ISPN-11795
> URL: https://issues.redhat.com/browse/ISPN-11795
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Reporter: Gustavo Fernandes
> Priority: Major
> Labels: query-ispn11
> Fix For: 11.0.0.Final
>
>
> * Custom FieldBridges
> * AnalyzerDef
> * Index time boost
> * Analyzer Discriminator
> * Default Analyzer
> * Default IndexNullAs
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months