[
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16850577#comment-16850577
]
Adrien Grand commented on LUCENE-8362:
--------------------------------------
Thanks Atri. I missed the part about "exactly match" in your previous comment.
In general exact matches on both the min and max value are not a good use-case
for range fields, you can do this more efficiently by concatenating the min and
max values and storing them in a StringField. Where range fields become more
interesting is when you want to find ranges that intersect, cross, contain or
are within the query range. I'd suggest starting with intersection now, and we
could potentially do the other ones as a follow-up? Maybe we could try to reuse
RangeFieldQuery#QueryType which already has the logic for matching ranges based
on various relations.
- BinaryRangeDocValues has an internal flag called collectionCompleted, which
seems to be used as a protection in case nextDoc/advance are called on an
exhausted iterator, but this should not be necessary: DocIdSetIterator javadocs
say that the behavior is undefined in such a case, we don't need to worry about
it.
- BinaryRangeDocValues allocates a new byte[] for every document, we should
avoid this as these methods are called in very tight loops.
- BinaryRangeDocValues#decodeRanges should take into account the BytesRef
offset.
- Can we move tests to a new class instead of adding to TestDocValuesQueries?
- Tests don't seem to test much, they keep indexing the same range over and
over, we should index a mix of ranges that match and others that don't?
> 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-approach2.patch, LUCENE-8362.patch,
> LUCENE-8362.patch, 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]
