[
https://issues.apache.org/jira/browse/SOLR-12074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691253#comment-16691253
]
David Smiley commented on SOLR-12074:
-------------------------------------
bq. How would this work with facet-sorting on index and the stats component?
Would it behave as a numeric or a String field?
numeric
bq. +1, it's important for it to be the same field in the schema for both
usability, and so that solr knows how to optimize single-valued lookups.
I agree that's best. This is more work than some new set of fields expressly
for lookup but so be it. We want a single field that can have distinct options
for tweaking the need for a range index and a lookup index independently. Lets
say we add a new two new booleans: lookupIndexed (or valueIndexed) and
rangeIndexed? The presence of indexed=true will pick defaults for those two as
we see fit. The ship hasn't sailed; we are adding further specificity on what
type of index(es).
We could put these options on PointField so that users need not go mess with
their schema. But then it's regrettable that we have "PointField" on this
field type and its subclass as it's suggestive of Lucene PointValues which
implies BKD. Or we create a new numeric subclass of NumericFieldType (peer to
TrieField & PointField). I'm not sure what to call it but it's the subclasses
that have the primitive types in their names (Long, Double, ...) that users see
in the schema. In this scheme they might simply be LongField and DoubleField
etc. What do you think? I think it's more user friendly. Even with such
generic/universal names, it doesn't prevent some future change in underlying
implementation using luceneMatchVersion.
> Add numeric typed equivalents to StrField
> -----------------------------------------
>
> Key: SOLR-12074
> URL: https://issues.apache.org/jira/browse/SOLR-12074
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
> Reporter: David Smiley
> Priority: Major
> Labels: newdev, numeric-tries-to-points
>
> There ought to be numeric typed equivalents to StrField in the schema. The
> TrieField types can be configured to do this with precisionStep=0, but the
> TrieFields are deprecated and slated for removal in 8.0. PointFields may be
> adequate for some use cases but, unlike TrieField, it's not as efficient for
> simple field:value lookup queries. They probably should use the same
> internal sortable full-precision term format that TrieField uses (details
> currently in {{LegacyNumericUtils}} (which are used by the deprecated Trie
> fields).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
