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

["Jason Gerlowski (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Gerlowski updated SOLR-11691:
-----------------------------------
    Attachment: SOLR-11691.patch
                repro.sh

I've attached a patch to correct this behavior.  With this patch, CREATEALIAS now supports a proper JSON array {{["a", "b"]}}, as well as the previously accepted formats (comma-delimited values, and comma-delimited values inside a JSON array).

Also attached is a bash script reproducing the problem (and exhibiting the correct behavior when the patch has been applied).



> 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
>         Attachments: SOLR-11691.patch, repro.sh
>
>
> 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 property 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