You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2015/12/12 00:09:46 UTC

[jira] [Commented] (SOLR-8406) AddSchemaFieldsUpdateProcessorFactory should handle list fields better

    [ https://issues.apache.org/jira/browse/SOLR-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053757#comment-15053757 ] 

Hoss Man commented on SOLR-8406:
--------------------------------

A better way to put that might be...

{panel}
If you are using AddSchemaFieldsUpdateProcessorFactory, and there is a mapping X such that:
* The fieldType refered to by X is multiValued="false"
* A SolrInputDocument contains multiple values for a field which (currently) matches the mapping X

Then, one of the following 2 things should happen:
* The "newField" call made by AddSchemaFieldsUpdateProcessorFactory should explicitly include multiValued="true" when adding the field using the type specified by X
* The X mapping should be ignored since the _cardinality_ of values in the doc vs the multivalued-ness of the fieldType don't align.
{panel}

I'm a proponent of the later choice, because it means you could have fieldtypes like this..

{code}
<fieldType name="int" docValues="true" stored="true" indexed="true" multiValued="false" />
<fieldType name="ints" docValues="false" stored="true" indexed="true" multiValued="true" />
{code}
...and ordered valueType mappings like this...
{code}
<lst name="typeMapping">
  <str name="valueClass">java.lang.Integer</str>
  <str name="fieldType">int</str> <!-- efficiently sortable if only one value -->
</lst>
<lst name="typeMapping">
  <str name="valueClass">java.lang.Integer</str>
  <str name="fieldType">ints</str> <!-- multivalued fallback w/dif fieldType defaults -->
</lst>
{code}

But we could just as easily support either option with a {{<bool name="addMultiValuedFieldForSingleValuedTypes">true</bool>}} option on the update processor.


> AddSchemaFieldsUpdateProcessorFactory should handle list fields better
> ----------------------------------------------------------------------
>
>                 Key: SOLR-8406
>                 URL: https://issues.apache.org/jira/browse/SOLR-8406
>             Project: Solr
>          Issue Type: Improvement
>          Components: Data-driven Schema
>            Reporter: Timothy Potter
>
> paraphrasing from offline discussion with Hossman:
> bq. when AddSchemaFieldsUpdateProcessorFactory mappings refer to fieldtypes that are multivalued=false, it should either skip that mapping, or explicitly specify multivalued=true, when a document with values matching that mapping contains multiple values
> basically, I'm submitting a document with foo = [ "bar", "baz" ] and field guessing doesn't figure out that foo is multi-valued unless my default is set to strings ... 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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