[
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
Thanks for the review Adrien! I was hoping you'd chime in.
This addresses your two main concerns, I hope.
* Both equals() & hashCode() implementations were re-generated using
Objects.equals & Objects.hash. FYI I use IntelliJ which has multiple
templates, so I switched it to the template that uses these methods.
* explain() no longer calls advance to detect if the doc matches; instead it
uses the ValueSourceScorer.match method. I added a comment to clarify why this
is done.
I'd like to file a _separate_ issue for ValueSourceScorer implementations to
honor exists() when matching. I don't want that to delay or crowd out the
point of this issue.
> 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,
> 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]
