Issues
- Using a SearchSort instance in multiple queries with the Lucene backend has side effects and leads to unexpected resultsHSEARCH-4513Resolved issue: HSEARCH-4513Yoann Rodière
- After importing dependencies, the startup fails without configuring backend. Can you set a switch so that nothing is done when only dependencies are imported?HSEARCH-4477Resolved issue: HSEARCH-4477Yoann Rodière
- Customizable entity loading queries in mass indexerHSEARCH-4471
- Fetch only fields needed for indexing during index buildHSEARCH-1813
4 of 4
Using a SearchSort instance in multiple queries with the Lucene backend has side effects and leads to unexpected results
Fixed
Description
Details
Assignee
Yoann RodièreYoann RodièreReporter
Yoann RodièreYoann RodièreComponents
Sprint
NoneFix versions
Priority
Major
Details
Details
Assignee
Yoann Rodière
Yoann Rodière
Reporter
Yoann Rodière
Yoann RodièreComponents
Sprint
None
Fix versions
Priority
MajorCreated March 18, 2022 at 3:57 PM
Updated April 6, 2022 at 2:54 PM
Resolved March 21, 2022 at 8:14 AM
Activity
Show:
It seems the creation of a
SearchQuerymutates aSearchSortby callingorg.hibernate.search.backend.lucene.types.sort.comparatorsource.impl.LuceneFieldComparatorSource#setOriginalParentQuery(the comparator source being a component of theSearchSort).Thus, if we create two queries with the same
SearchSortinstance, the secondSearchQuerywill have the final word on what gets passed tosetOriginalParentQuery, and then executing the firstSearchQuerywill lead to unexpected results (since the sort uses the wrong Lucene query internally).SearchSortshould be immutable in order to avoid that.