lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LUCENE-6720) new FunctionRangeQuery, plus ValueSourceScorer improvements
Date Wed, 05 Aug 2015 04:26:04 GMT

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message