[jira] [Commented] (SOLR-6045) atomic updates w/ solrj + BinaryRequestWriter aren't working when adding multiple fields w/ same name in a single SolrInputDocument

["Scott Lindner (JIRA)" <ji...@apache.org>]

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

Scott Lindner commented on SOLR-6045:
-------------------------------------

Digging into this more it's due to the fact that DistributedUpdateProcessor assumes the top-most element in a field's value must be a Map, but when you call addField(..) multiple times this creates an array list of Maps.  So code like:

{code}
  public static boolean isAtomicUpdate(final AddUpdateCommand cmd) {
    SolrInputDocument sdoc = cmd.getSolrInputDocument();
    for (SolrInputField sif : sdoc.values()) {
      if (sif.getValue() instanceof Map) {
        return true;
      }
    }
    return false;
  }
{code}

does not treat this as an atomic update.  Also code in the getUpdatedDocument function also makes these same assumptions.

Now this doesn't explain why the behavior is different when using the BinaryRequestWriter vs. the OOB xml so something is definitely screwy here as simply changing the request transport mechanism should have no impact on behavior.

I'm not sure which is the intended behavior but from where I stand it would be nice to be able to just call .addField multiple times and have the API support this - otherwise I need to build / track my own state for values while I'm creating the document and combine them myself.

> atomic updates w/ solrj + BinaryRequestWriter aren't working when adding multiple fields w/ same name in a single SolrInputDocument
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-6045
>                 URL: https://issues.apache.org/jira/browse/SOLR-6045
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.8
>         Environment: client & server both on 4.8
>            Reporter: Scott Lindner
>
> I'm using the following code snippet:
> {code}
>         HttpSolrServer srvr = new HttpSolrServer("HOST:8983/solr/foo-test");
>         SolrInputDocument sid = new SolrInputDocument();
>         sid.addField("id", "some_id");
>         Map<String, String> fieldModifier = Maps.newHashMap();
>         fieldModifier.put("set", "new_value1");
>         sid.addField("field1", fieldModifier);
>         Map<String, Object> fieldModifier2 = Maps.newHashMap();
>         fieldModifier2.put("set", "new_value2");
>         sid.addField("field1", fieldModifier2);
>         srvr.add(sid);
>         srvr.commit();
> {code}
> *NOTE*: the important part here is that I am using the same field name and adding 2 values separately to the same solr document.
> This produces the correct values in the index.  Here is the output from searching from the admin console:
> {noformat}
> "field1": [
>           "new_value1",
>           "new_value2"
>         ]
> {noformat}
> However if I modify the above code to have the following lines after creating the SolrServer:
> {code}
>         srvr.setRequestWriter(new BinaryRequestWriter());
>         srvr.setParser(new BinaryResponseParser());
> {code}
> Then the values that are returned are incorrect:
> {noformat}
> "field1": [
>           "{set=new_value1}",
>           "{set=new_value2}"
>         ]
> {noformat}
> This also behaves the same if I use the CloudSolrServer as well.
> If I modify my code to look like the following:
> {code}
>         Map<String, List<String>> fieldModifier = Maps.newHashMap();
>         fieldModifier.put("set", Lists.newArrayList("new_value1", "new_value2"));
>         sid.addField("field1", fieldModifier);
> {code}
> Then this *does* work with the BinaryRequestWriter.  So this seems to be an issue when calling addField() with the same name multiple times.
> In the process of debugging this I think I also uncovered a few other similar issues but I will file separate bugs for those.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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