[
https://issues.apache.org/jira/browse/SOLR-12074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693751#comment-16693751
]
Tomás Fernández Löbbe commented on SOLR-12074:
----------------------------------------------
bq. so that solr knows how to optimize single-valued lookups.
You mean, in case of term queries use the terms if available, otherwise use
points, right? I think that would be good, the same as we do for
IndexOrdDocValuesQuery when we have both options.
bq. If we could turn back time...
I think Hoss suggested something like that at the time (not sure if in a Jira
comment or just talking to me during some conference). The thought was that
this would be a full replacement of Trie* fields, similar to how older numerics
were replaced, but yes, it could have been better. The one issue though, would
that people is selecting the implementation in their schema and it would have
been "Trie*", which were deprecated and going away.
bq. In this scheme they might simply be LongField and DoubleField etc
The problem I see with this is that, today we choose between the Point* impl or
terms (String or equivalent), but tomorrow there may be a new implementation,
so how do we go from there? Add more attributes? what if the new implementation
is also targetted at range queries?
I'd go with an extra attribute in the current Point* implementation as Yonik
suggested, maybe "terms=true" or something. This is consistent with how other
Solr schema attributes are converted into Lucene fields: stored=true-> Add
StoredField, docValues=true-> Add a DocValue field
> 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]
