[ 
https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855432#comment-16855432
 ] 

Adrien Grand commented on LUCENE-8362:
--------------------------------------

Thanks [~atris] I like how this is structured in general.
+1 to follow up with another patch that adds other types of queries

Here is my feedback:
 - let's remove the EQUALS query, I don't think there are good use-cases for it
 - can you make fields protected rather than public in BinaryRangeDocValuesField
 - hashCode on a byte[] is the identity hashcode, you might want to use 
Arrays#hashcode instead, and likewise use Arrays#equals instead of == in the 
equals implementation
 - BinaryRangeFieldRangeQuery#toString seems to never be used as it is always 
overridden and sub classes don't call "super.toString"? This seems to be the 
case for rewrite() as well?


> 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, 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]

Reply via email to