"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
expect.
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.
-- Jack Krupansky
-----Original Message-----
From: Robert Krüger
Sent: Thursday, June 06, 2013 7:25 AM
To: solr-user@lucene.apache.org
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.
Thanks,
Robert
On Thu, Jun 6, 2013 at 12:18 AM, Chris Hostetter
<hossman_luc...@fucit.org> 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...
http://wiki.apache.org/solr/Atomic_Updates#Stored_Values
-Hoss
