Fixed
Details
Assignee
Guillaume SmetGuillaume SmetReporter
Yoann RodièreYoann RodièreComponents
Sprint
NoneFix versions
Priority
Major
Details
Details
Assignee
Guillaume Smet
Guillaume SmetReporter
Yoann Rodière
Yoann RodièreComponents
Sprint
None
Fix versions
Priority
Created October 22, 2018 at 9:49 AM
Updated November 28, 2018 at 3:43 PM
Resolved October 25, 2018 at 10:04 AM
The idea is to have one "builder factory" instance for each field and each DSL (predicate/sort/projection). See
org.hibernate.search.backend.lucene.document.model.impl.LuceneIndexSchemaFieldNode#predicateBuilderFactory
for example.In https://hibernate.atlassian.net/browse/HSEARCH-3222#icft=HSEARCH-3222 Guillaume is working on taking this path for projections as well, and I think it's the more future-proof choice.
Currently we use this pattern rather inconsistently; for Lucene it's mostly used everywhere, but not for Elasticsearch.
Also, we have some issues with the "factory" interfaces:
I think the
equals
/hashCode
on theLuceneFieldPredicateBuilderFactory
interface doesn't serve any purpose. In fact, it's only implemented in a single factory, and according to Coveralls it's never called in our tests. I think we can safely remove these methods from both the interface and implementations, I must have forgotten to do it when I introducedisDSLCompatibleWith
.Ultimately we should do the same for SortContributors (declare an
isXXXCompatible
method instead ofequals
/hashCode
).https://github.com/hibernate/hibernate-search/pull/1759#discussion_r227247517