Trey Grainger created SOLR-9529:

             Summary: Dates Dynamic Field Inconsistently Defined in Schemas
                 Key: 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" 
<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" 
<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" 

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 

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

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to