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

2017-12-07 Thread David Smiley (JIRA)

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

David Smiley updated SOLR-11691:

Attachment: SOLR-11691.patch

I tweaked it slightly and added a formal test.  Thanks [~noble.paul].

[~jpountz] shall I commit this to 7.2?  It's a bug but not a serious one.

> 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, SOLR-11691.patch, 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



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

2017-12-06 Thread Noble Paul (JIRA)

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

Noble Paul updated SOLR-11691:
--
Attachment: SOLR-11691.patch

untested patch , isn't this better

> 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, 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



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

2017-12-06 Thread Jason Gerlowski (JIRA)

 [ 
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



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

2017-11-28 Thread Gus Heck (JIRA)

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

Gus Heck updated SOLR-11691:

Description: 
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.

  was:
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