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

Adrien Grand commented on LUCENE-10162:
---------------------------------------

bq. Is it correct to assume that this is only "syntactic sugar" and that under 
the hood we'll still add IntPoint and NumericDocValuesField the doc?

Correct.

bq. would it make sense to desugar in Document#add? If the field is composite 
(eg. IntField), then we add the two fields instead of one

I don't think there's an easy way to do this. Lucene Field classes tend to be 
very simple, they mostly wrap a value and configure a FieldType object that 
describes how the data should be indexed. The way I was thinking of addressing 
this issue would consist of implementing these LongField/IntField/... classes 
from scratch without trying to reuse LongPoint/IntPoint/... or 
NumericDocValuesField/SortedNumericDocValuesField.

> Add IntField, LongField, FloatField and DoubleField classes to index both 
> points and doc values
> -----------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-10162
>                 URL: https://issues.apache.org/jira/browse/LUCENE-10162
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Priority: Minor
>
> Currently we have IntPoint, LongPoint, FloatPoint and DoublePoint on the one 
> hand, and NumericDocValuesField and SortedNumericDocValuesField on the other 
> hand.
> When we introduced these classes, this distinction made sense: use the 
> XXXPoint classes if you want your numeric fields to be searchable and the 
> XXXDocValuesField classes if you want your numeric fields to be 
> sortable/aggregatable.
> However since then, we introduced logic to take advantage of doc values for 
> filtering (IndexOrDocValuesQuery) and enhanced sorting to take advantage of 
> the Points index to skip non-competitive documents. So even if you only need 
> searching, or if you only need sorting, it's likely a good idea to index both 
> with points *and* doc values.
> Could we make this easier on users by having XXXField classes that 
> automatically do it as opposed to requiring users to add both an XXXPoint and 
> an XXXDocValuesField for every numeric field to their index? This could also 
> make consuming these fields easier, e.g. factory methods for range queries 
> could automatically use IndexOrDocValuesQuery.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to