[GitHub] [lucene] nknize commented on pull request #749: LUCENE-10466: IndexSortSortedNumericDocValuesRangeQuery unconditionally assumes the usage of the LONG-encoded SortField

[GitBox <gi...@apache.org>]

nknize commented on PR #749:
URL: https://github.com/apache/lucene/pull/749#issuecomment-1087817810

   > > In my opinion, long-term this IndexSortSortedNumericDocValuesRangeQuery should no longer be exposed to users. Lucene would have long/int/double/float fields ([LUCENE-10162](https://issues.apache.org/jira/browse/LUCENE-10162)) that would have factory methods to produce queries,
   > 
   > 
   > Does this future state assume `{Int | Long | ...}Point` and `NumericDocValuesField` will no longer be mutually exclusive?
   > 
   > Followup (before this merges): I'm trying to understand if we are planning to eliminate the ability for folks to index just doc values or just points when they are willing to sacrifice performance to save disk storage. Sounds punitive but there are users in this category.
   > 
   > Follow Followup: Exposing a setting on the new `{Int | Long | ...}Field` to index either or both (doc values, points) seems reasonable?
   
   I was hoping to clarify what the plan is before merging but I haven't seen and response don't want to hold up the fix. Can we continue this thread on the referenced Jira issue?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org