[
https://issues.apache.org/jira/browse/LUCENE-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506530#comment-17506530
]
Julie Tibshirani edited comment on LUCENE-10466 at 3/14/22, 8:40 PM:
---------------------------------------------------------------------
Thank you [~reta] for reporting this. I had noticed the same thing when
integrating IndexSortSortedNumericDocValuesRangeQuery into Elasticsearch but
forgot to follow up!! I would be happy to help review a PR if you're up for it.
For context, how did you run into this? How does it relate to deletions in
nearest vector search (https://issues.apache.org/jira/browse/LUCENE-10040) ?
was (Author: julietibs):
Thank you [~reta] for reporting this. I had noticed the same thing when
integrating IndexSortSortedNumericDocValuesRangeQuery into Elasticsearch but
forgot to follow up!! I would be happy to help review a PR if you're up for it.
For context, how did you run into this? How does it relate to deletions in
nearest vector search (https://issues.apache.org/jira/browse/LUCENE-10040)?
> IndexSortSortedNumericDocValuesRangeQuery unconditionally assumes the usage
> of the LONG-encoded SortField
> ---------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-10466
> URL: https://issues.apache.org/jira/browse/LUCENE-10466
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring
> Affects Versions: 9.0
> Reporter: Andriy Redko
> Priority: Minor
>
> We have run into this issue while migrating to OpenSearch and making changes
> to accommodate https://issues.apache.org/jira/browse/LUCENE-10040. It turned
> out that *IndexSortSortedNumericDocValuesRangeQuery* unconditionally assumes
> the usage of the LONG-encoded {*}SortField{*}, as could be seen inside
> *static ValueComparator loadComparator* method
> {noformat}
> @SuppressWarnings("unchecked")
> FieldComparator<Long> fieldComparator = (FieldComparator<Long>)
> sortField.getComparator(1, 0);
> fieldComparator.setTopValue(topValue);
> {noformat}
>
> Using the numeric range query (in case of sorted index) with anything but
> LONG ends up with class cast exception:
> {noformat}
> > java.lang.ClassCastException: class java.lang.Long cannot be cast to
> class java.lang.Integer (java.lang.Long and java.lang.Integer are in module
> java.base of loader 'bootstrap')
> > at
> org.apache.lucene.search.comparators.IntComparator.setTopValue(IntComparator.java:29)
> > at
> org.apache.lucene.sandbox.search.IndexSortSortedNumericDocValuesRangeQuery.loadComparator(IndexSortSortedNumericDocValuesRangeQuery.java:251)
> > at
> org.apache.lucene.sandbox.search.IndexSortSortedNumericDocValuesRangeQuery.getDocIdSetIterator(IndexSortSortedNumericDocValuesRangeQuery.java:206)
> > at
> org.apache.lucene.sandbox.search.IndexSortSortedNumericDocValuesRangeQuery$1.scorer(IndexSortSortedNumericDocValuesRangeQuery.java:170)
> {noformat}
> Simple test case to reproduce (for
> TestIndexSortSortedNumericDocValuesRangeQuery):
> {noformat}
> public void testIndexSortDocValuesWithIntRange() throws Exception {
> Directory dir = newDirectory();
> IndexWriterConfig iwc = new IndexWriterConfig(new MockAnalyzer(random()));
> Sort indexSort = new Sort(new SortedNumericSortField("field",
> SortField.Type.INT, false));
> iwc.setIndexSort(indexSort);
>
> RandomIndexWriter writer = new RandomIndexWriter(random(), dir, iwc);
> writer.addDocument(createDocument("field", -80));
>
> DirectoryReader reader = writer.getReader();
> IndexSearcher searcher = newSearcher(reader); // Test ranges
> consisting of one value.
> assertEquals(1, searcher.count(createQuery("field", -80, -80)));
> writer.close();
> reader.close();
> dir.close();
> } {noformat}
>
> The expectation is that *IndexSortSortedNumericDocValuesRangeQuery* should
> not fail with class cast but correctly convert the numeric values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
