[
https://issues.apache.org/jira/browse/SOLR-11023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16099688#comment-16099688
]
Adrien Grand commented on SOLR-11023:
-------------------------------------
bq. So I think we really still want to use ints for the store/index/docvalues
and deal with all the String/label conversion only in response writing and
query parsing. Obviously we'll still want to use
NumericUtils.intToSortableBytes for the indexed bytes so that our range queries
are still "numeric" and not "alphabetical"
It sounds good to me.
> Need SortedNumerics/Points version of EnumField
> -----------------------------------------------
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Labels: numeric-tries-to-points
> Attachments: SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use
> "LegacyIntField" to index the int value associated with each of the enum
> values, in addition to using SortedSetDocValuesField when {{docValues="true"
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality
> usecases like EnumField, but either way we should think about a new variant
> of EnumField that doesn't depend on
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses
> SortedNumericDocValues.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
