[jira] [Commented] (SOLR-11691) v2 api for CREATEALIAS fails if given a list with more than one element
[
https://issues.apache.org/jira/browse/SOLR-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282049#comment-16282049
]
ASF subversion and git services commented on SOLR-11691:
Commit d17d331ec06f31c1abb625f53d3a0450e0c1c83c in lucene-solr's branch
refs/heads/branch_7_2 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d17d331 ]
SOLR-11691: Bug: V2 requests for create-alias didn't work when the collections
param was an array.
(cherry picked from commit fe8dca8)
> 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] [Commented] (SOLR-11691) v2 api for CREATEALIAS fails if given a list with more than one element
[
https://issues.apache.org/jira/browse/SOLR-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282047#comment-16282047
]
ASF subversion and git services commented on SOLR-11691:
Commit fe8dca8ea2ef9f58d106e109e2d02c0423e508c4 in lucene-solr's branch
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fe8dca8 ]
SOLR-11691: Bug: V2 requests for create-alias didn't work when the collections
param was an array.
(cherry picked from commit 5448274)
> 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] [Commented] (SOLR-11691) v2 api for CREATEALIAS fails if given a list with more than one element
[
https://issues.apache.org/jira/browse/SOLR-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282045#comment-16282045
]
ASF subversion and git services commented on SOLR-11691:
Commit 5448274f26191a9882aa5c3020e3cbdcbf93551c in lucene-solr's branch
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5448274 ]
SOLR-11691: Bug: V2 requests for create-alias didn't work when the collections
param was an array.
> 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] [Commented] (SOLR-11691) v2 api for CREATEALIAS fails if given a list with more than one element
[
https://issues.apache.org/jira/browse/SOLR-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282012#comment-16282012
]
Adrien Grand commented on SOLR-11691:
-
The patch looks low risk (but I'm not familiar with this part of the code, so I
could be wrong) so I'd say +1 to backport to 7.2.
> 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] [Commented] (SOLR-11691) v2 api for CREATEALIAS fails if given a list with more than one element
[
https://issues.apache.org/jira/browse/SOLR-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281864#comment-16281864
]
Jason Gerlowski commented on SOLR-11691:
Not to turn my back on my work, but let's go with Noble's solution. I didn't
realize that we could get the collections as a List from ZkNodeProps, without
monkeying around with removing brackets, etc.
My bad.
> 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] [Commented] (SOLR-11691) v2 api for CREATEALIAS fails if given a list with more than one element
[
https://issues.apache.org/jira/browse/SOLR-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
