lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky" <>
Subject Re: copyField generates "multiple values encountered for non multiValued field"
Date Thu, 06 Jun 2013 11:52:14 GMT
"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?

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 

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>();
    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.

-- Jack Krupansky

-----Original Message----- 
From: Robert Kr├╝ger
Sent: Thursday, June 06, 2013 7:25 AM
Subject: Re: copyField generates "multiple values encountered for non 
multiValued field"

I don't know what I have to do to use the atomic update feature but I
am not aware of using it. But the way you describe it, it means that
the copyField directive does not overwrite the existing field content
and that's an easy explanation to what is happening in my case. Then
the second update (which I do manually, i.e. read current state,
manipulate fields and then add the document with the same id) will
lead to this. That was not so obvious to me from the docs.



On Thu, Jun 6, 2013 at 12:18 AM, Chris Hostetter
<> wrote:
> : I updated the Index using SolrJ and got the exact same error message
> there aren't a lot of specifics provided in this thread, so this may not
> be applicable, but if you mean you actaully using the "atomic updates"
> feature to update an existing document then the problem is that you still
> have the existing value in your name2 field, as well as another copy of
> the "name" field evaluated by copyField after the updates are applied...
> -Hoss 

View raw message