Description
depends on
follows up on
relates to
Activity
Show:
Yoann Rodière February 25, 2019 at 12:30 PM
For now, we’re going with solution 1: “all Elasticsearch analyzer definitions are pushed to all Elasticsearch indexes”. We will improve on that later with per-index analyzer definitions.
This should already work, but we need to add tests in the backend TCK once HSEARCH-3312 is implemented (to allow to select another analyzer when querying).
Yoann Rodière July 12, 2018 at 9:22 AM
A more detailed explanation of how to work around this issue: https://discourse.hibernate.org/t/cannot-find-the-second-analyzer-when-using/1043/4?u=yoann
Sanne Grinovero January 22, 2017 at 12:47 AM
Deferring this as there are alternatives: people don't have to use our Query DSL and can edit the index schema.
Details
Details
Assignee
Reporter
Components
Sprint
None
Fix versions
Priority
One can imagine defining analyzers that will only be used when querying, for instance when the analyzer used when indexing creates ngrams.
In this case, analyzers are not referenced in Hibernate Search's internal entity metamodel.
Unfortunately, Hibernate Search only adds to the index settings those analyzers that are referenced in the related entity metamodel. Which means those analyzers will not be available when querying, when using
org.hibernate.search.query.dsl.impl.ConnectedQueryContextBuilder.HSearchEntityContext.overridesForField(String, String)for instance.We should make sure that either:
all Elasticsearch analyzer definitions are pushed to all Elasticsearch indexes. Downsides: this will trigger unnecessary updates when using the MERGE strategy (see https://github.com/hibernate/hibernate-search/pull/1271), and we may have issues when users have both Elasticsearch and embedded Lucene indexes.
OR users are able to explicitly mark analyzer definitions as available in a given Elasticsearch index.