[
https://issues.apache.org/jira/browse/SOLR-12074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693838#comment-16693838
]
Jan Høydahl commented on SOLR-12074:
------------------------------------
Either new types or additional attributes may work.
I'd love it if the primitive types such as "int", "long", "float", "date",
"boolean"... were "just there" and worked super fast for both lookups, rang,
facet and sorting without any further hoops. Now that the plain fieldType names
like "int" are available (the point types uses "pint"), what if we added a
brand new schema tag to auto-register all these, and let it defaults to "true"
from schema-version 1.7:
{code:xml}
<!-- The primitiveTypes tag, when set to true, will auto register all primitive
field types under the
names 'int', 'long', 'float', 'double', 'date', 'boolean', based on
PointField types, and optimized
for term lookups (indexed=true), range queries (bkdIndex=true) and sorting
and faceting (docValues=true).
Individual fields using these types may further enable/disable any of
those.
If dynamicFIeldMappings is true, Solr will auto-register '*_i'->'int',
'*_l'->'long' etc as well.
-->
<primitiveTypes enable="true" dynamicFieldMappings="true" />{code}
Users who prefer to hand-edit all the nitty gritty details of the field type
definitions may disable this, or they may override various flags on the field
definitions. Imagine how small and compact a schema.xml could be for simple use
cases!
> 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]
