lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrien Grand (JIRA)" <>
Subject [jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
Date Wed, 22 May 2019 12:07:00 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message