On Thu, Jun 6, 2013 at 1:52 PM, Jack Krupansky <j...@basetechnology.com> 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.
Robert
