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

["David Smiley (JIRA)" <ji...@apache.org>]

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

David Smiley commented on SOLR-11691:
-------------------------------------

Thanks [~gus_heck] for the detailed bug report and thanks [~gerlowskija] for contributing a solution and reproducibility script!  

I guess I'm okay with the overall approach of having CreateAliasCmd do this JSON parsing although it feels as though it should be on the v2 side somehow (which I am not familiar with so can't point you at a particular class).  [~noble.paul] do you have an opinion?

Assuming we stay the course... can we make this patch detect that it's JSON and if so parse it properly?  See Utils.fromJSON etc.  Your solution of stripping the brackets and quotes is a bit hokey.  And I'm not sure why you used commons-lang3 to call StringUtils when Solr has equivalents in StrUtils.


> 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
>            Assignee: David Smiley
>         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