[
https://issues.apache.org/jira/browse/LUCENE-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-6720:
---------------------------------
Attachment: LUCENE-6720__FunctionRangeQuery.patch
The attached patch implements the aforementioned functionality, including tests.
Notes:
ValueSourceScorer:
* marked as lucene.experimental; although might be considered internal.
FunctionValues explicitly returns this scorer, and Solr calls a method on it,
so I figured experimental over internal.
* removed deleted doc handling since it’s redundant at this layer; the bulk doc
scorer handles that.
* made abstract and made matches() abstract (renamed from matchesValue) to
clarify it’s typical use. matches() vs. matchesValue() is more consistent
(e.g. TwoPhaseIterator.matches), I feel. This rename caused some changes in a
bunch of files.
FunctionRangeQuery:
* Added basic test, including with deleting a doc.
* FYI discovered this Query is similar to DocValuesRangeQuery (now in Sandbox).
DVRQ is constant scoring, is specific to docValues (not generic ValueSource),
and won’t match docs with no value
* Future: don’t match if FunctionValues.exists() returns false? How to prevent
extra value fetching? Oddly, IntFieldSource & friends have an exist() method
that fetches the value to see if it’s 0. I don’t know why it should care.
Question: Should a FunctionRangeQuery/ValueSourceScorer actually be based on
the MutableValue API? I haven’t looked at that API much before now; it’s an
odd one. Presumably it’s existence is made to facilitate scenarios like
FunctionRangeQuery to avoid a bunch of type-specific code, since the
type-specific code is already in the MutableValue API? This would effectively
mean that IntDocValues (a subclass of ValueSource that has a FunctionValues) &
it’s type friends would have simpler implementations of getRangeScorer since
once the lower & upper Strings are parsed and loaded into a MutableValue of the
right type, a generic range scorer could handle it from there.
> new FunctionRangeQuery, plus ValueSourceScorer improvements
> -----------------------------------------------------------
>
> Key: LUCENE-6720
> URL: https://issues.apache.org/jira/browse/LUCENE-6720
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: David Smiley
> Assignee: David Smiley
> Attachments: LUCENE-6720__FunctionRangeQuery.patch
>
>
> This issue provides a new FunctionRangeQuery, which is basically a wrapper
> around ValueSourceScorer (retrieved from FunctionValues.getRangeScorer). It
> replaces ValueSourceFilter in the spatial module. Solr has a class by the
> same name which is similar but isn't suitable to being ported.
> Also, it includes refactorings to the ValueSourceScorer, to include
> performance enhancements by making it work with the TwoPhaseIterator API.
> note: I posted this to LUCENE-4251 initially but then felt it's really its
> own issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
