This may be related to the fact that the faceting field and original another regular field may have the same name, but have different mappings (most notably the facet field is not analyzer analyzed ), which means that the Elasticsearch mapping will be the one for whichever field we inspect last.
See https://github.com/hibernate/hibernate-search/blob/55d753e/orm/src/test/java/org/hibernate/search/test/query/facet/Car.java#L57..L64 for the conflicting regular/faceting fields : we have a "make" regular field, which is not analyzed, a "facetingNameCollision" regular field which *is* analyzed, and a facet named "facetingNameCollision" on the "make" regular field .
See https://github.com/hibernate/hibernate-search/commit/34f7eaafadeabbb75597306b20258db7ce198850 for the original commit introducing the {{@Facet}} annotation, that states in its commit message that facet fields should not be analyzed: "Adding verification that indexed field configured for faceting is not analyzed"
Since the The documentation states "In order to facet on a given indexed field, the field needs to be configured with the `@Facet` annotation. Also, **the field itself cannot be analyzed**.", maybe and we should simply we already throw an exception when we find a {{@Facet}} annotation on an analyzed field ? , *but* we don't detect name collisions between a facet and an unrelated field...
Or maybe Maybe we should always generate add a second version of the field for facetting suffix or prefix to faceting fields , like "<field name>_HSearch_facet" . ? Or we should detect such name collisions and throw exceptions?
StringFacetingTest.testStringFacetingWithNameCollision() has been disabled for Elasticsearch and should be enabled again when this is solved. |
|