[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845816#comment-16845816
]
Adrien Grand commented on LUCENE-8362:
--------------------------------------
I agree this could be useful in conjunction with IndexOrDocValuesQuery. Some
thoughts:
* other classes handle points and doc values on separate classes (eg.
LongPoint/NumericDocValuesField, LatLonPoint/LatLonDocValuesField), we should
do the same for consistency?
* we should document the limitation that there can be at most one value per
document due to the use of binary doc values
* can we have factory methods for doc value queries, so that something can be
done with these docvalue fields, preferrably with "Slow" in the name of the
factory method, like NumericDocValuesField#newSlowRangeQuery
> Add DocValue support for RangeFields
> -------------------------------------
>
> Key: LUCENE-8362
> URL: https://issues.apache.org/jira/browse/LUCENE-8362
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Nicholas Knize
> Priority: Minor
> Attachments: LUCENE-8362.patch
>
>
> I'm opening this issue to discuss adding DocValue support to
> {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range
> fields already provide the methods for encoding ranges as a byte array I
> think this could be as simple as adding syntactic sugar to existing range
> fields that simply build an instance of {{BinaryDocValues}} using that same
> encoding. I'm envisioning something like
> {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit
> other ideas or potential drawbacks to this approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
