lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kr├╝ger <>
Subject Re: copyField generates "multiple values encountered for non multiValued field"
Date Thu, 06 Jun 2013 14:41:59 GMT
On Thu, Jun 6, 2013 at 1:52 PM, Jack Krupansky <> wrote:
> "read current state, manipulate fields and then add the document with the
> same id)"
> Ahh... then you have an IMPLICIT reference to the field in your Java code -
> you explicitly told Solr that you wanted to start with all existing field
> values. Just because a field is the target of a copyField doesn't make it
> any different from any other field when reading. Although, it does beg the
> question of whether or not this field should be stored or not - that's a
> data modeling question that only you can resolve. Do queries need to
> retrieve this field?
you're right. in my concrete use case it does not need to to be stored.

> Be sure to null out any values for any fields that are sourced by copy
> fields. Otherwise, yes, duplicated values would be exactly what you should
> expect.
yes, I will do that.

> Is there any reason that you can't simply use atomic update - create a new
> document with the same document id but with only "set" values for the fields
> to be changed? There is also "add" for multivalued fields.
> There isn't great doc for this. Basically, the value for every non-ID field
> would be a Map object (HashMap) with a "set" key whose value is the new
> field value.
> Here's a code fragment for setting one field:
>    SolrInputDocument doc2 = new SolrInputDocument();
>    Map<String,String> fpValue2 = new HashMap<String, String>();
>    fpValue2.put("set","fp2");
>    doc2.setField("FACTURES_PRODUIT", fpValue2);
> You need a separate Map object for each field to be set or "add"ed for
> appending to a multivalued field. And you need a simple (non-Map) value for
> your ID field.

thanks for the info! the code is a lot older than solr 4.0, so that
option was not available at the time of its writing. I will check if
it makes sense to use that feature. most likely yes.


View raw message