[jira] [Created] (SOLR-11691) v2 api for CREATEALIAS fails if given a list with more than one element

["Gus Heck (JIRA)" <ji...@apache.org>]

Gus Heck created SOLR-11691:
-------------------------------

             Summary: v2 api for CREATEALIAS fails if given a list with more than one element
                 Key: SOLR-11691
                 URL: https://issues.apache.org/jira/browse/SOLR-11691
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
          Components: v2 API
    Affects Versions: master (8.0)
            Reporter: Gus Heck


Successful, correct:

{code}
{
  "create-alias" : {
    "name": "testalias1",
    "collections":["collection1"]
  }
}
{code}

Successful, but wrong:
{code}
{
  "create-alias" : {
    "name": "testalias1",
    "collections":["collection1,collection2"]
  }
}
{code}

Fails, but should work based on details in _introspect:
{code}
{
  "create-alias" : {
    "name": "testalias2",
    "collections":["collection1","collection2"]
  }
}
{code}

The error returned is:
{code}
{
    "responseHeader": {
        "status": 400,
        "QTime": 25
    },
    "Operation createalias caused exception:": "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Can't create collection alias for collections='[collection1, collection2]', '[collection1' is not an existing collection or alias",
    "exception": {
        "msg": "Can't create collection alias for collections='[collection1, collection2]', '[collection1' is not an existing collection or alias",
        "rspCode": 400
    },
    "error": {
        "metadata": [
            "error-class",
            "org.apache.solr.common.SolrException",
            "root-error-class",
            "org.apache.solr.common.SolrException"
        ],
        "msg": "Can't create collection alias for collections='[collection1, collection2]', '[collection1' is not an existing collection or alias",
        "code": 400
    }
}
{code}

whereas 
{code}
GET localhost:8981/api/c
{code}

yields

{code}
{
    "responseHeader": {
        "status": 0,
        "QTime": 0
    },
    "collections": [
        "collection2",
        "collection1"
    ]
}
{code}

Intropsection shows:
{code}
     "collections": {
         "type": "array",
         "description": "The list of collections to be known as this alias.",
          "items": {
              "type": "string"
           }
      },
{code}

Basically the argument is documented as an array, but parsed as a string (I suspect it's parsed as a list but then the toString value of the list is used, but haven't checked). We have a conflict between what is natural for expressing a list in JSON (an array) and what is natural for expressing a list as a parameter (comma separation). I'm unsure how best to resolve this, as it's a question of making "direct translation" to v2 work vs making v2 more natural. I tend to favor accepting an array and therefore making v2 more natural which would be more work, but want to know what others think. From a back compatibility perspective, that direction also makes this clearly a bug fix rather than a breaking change since it doesn't match the _introspect documentation. I also haven't tried looking at old versions to find any evidence as to whether the documented form worked previously... so I don't know if this is a regression or if it never worked.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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