Trey Grainger created SOLR-9529:
-----------------------------------
Summary: Dates Dynamic Field Inconsistently Defined in Schemas
Key: SOLR-9529
URL: https://issues.apache.org/jira/browse/SOLR-9529
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Trey Grainger
Priority: Minor
There is a nice convention across all of the schemas that ship with Solr to
include field types for single valued fields (i.e. "string" -> "*_s", "boolean"
-> "*_b") and separate field types for multivalued fields (i.e. "strings" ->
"*_ss", "booleans" -> "*_bs"). Those definitions all follow the pattern (using
"string" as an example):
<fieldType name="string" class="solr.StrField" sortMissingLast="true"/>
<fieldType name="strings" class="solr.StrField" sortMissingLast="true"
multiValued="true"/>
<dynamicField name="*_s" type="strings" indexed="true" stored="true"/>
<dynamicField name="*_ss" type="strings" indexed="true" stored="true"/>
For some reason, however, the "date" field type doesn't follow this pattern,
and is instead defined (inconsistently) as follows:
<fieldType name="date" class="solr.TrieDateField" positionIncrementGap="0"
precisionStep="0"/>
<fieldType name="dates" class="solr.TrieDateField" positionIncrementGap="0"
multiValued="true" precisionStep="0"/>
<dynamicField name="*_dt" type="date" indexed="true" stored="true"/>
<dynamicField name="*_dts" type="date" multiValued="true" indexed="true"
stored="true"/>
Note specifically that the "*_dts" field should instead be referencing the
"dates" type and not the "date" type, and that subsequently the
multiValued="true" setting would become unnecessary on the "*_dts" dynamicField
definition.
I'll get a patch posted for this. Note that nothing is functionally broken,
it's just inconsistent and could be confusing for someone looking through the
schema or seeing their multivalued dates getting indexed into the field type
defined for single valued dates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
