Alexandre Rafalovitch commented on SOLR-9529:

We also have inconsistency with docValues, we have field types present in one 
but not another, etc.

The question is also whether we really need to ship most of the definitions 
with each example? This causes both drift over type and confusion for users.

One alternative is to have absolutely minimal examples (plus one kitchen sink) 
and then have a mechanism to add those additional field definitions as needed 
via REST API. Perhaps with using Admin UI and some sort of templates.

> 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

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to