[jira] [Commented] (SOLR-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319355#comment-16319355
]
ASF subversion and git services commented on SOLR-11631:
Commit c66d1d1ffaa8e1f4204bbf83db5e3527573330ed in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c66d1d1 ]
SOLR-11631: fix precommit
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319356#comment-16319356
]
ASF subversion and git services commented on SOLR-11631:
Commit e538792d298d85637ebaa88b5e0ac090eeb1bb20 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e538792 ]
SOLR-11631: fix precommit
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319347#comment-16319347
]
ASF subversion and git services commented on SOLR-11631:
Commit 4f81bb3cfc9f6bcc1f4dedea90064ba66999e3aa in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f81bb3 ]
SOLR-11631: fix another test
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319348#comment-16319348
]
ASF subversion and git services commented on SOLR-11631:
Commit f6eae40a1b2304dd61e348b2d4af110f6e2a1a66 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f6eae40 ]
SOLR-11631: fix another test
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318825#comment-16318825
]
Varun Thacker commented on SOLR-11631:
--
> Varun Thackerit is not necessarily useful to a human user. However, it's
> useful for a program to know what exception was thrown
Noble are you saying that knowing {{root-error-class}} and {{error-class}} is
useful for the machine? Can you give an example for what actions could one take?
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318735#comment-16318735
]
ASF subversion and git services commented on SOLR-11631:
Commit 5aa60485e654509418c99db09522a364dad2fed9 in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5aa6048 ]
SOLR-11631: fix Solrj tests
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16318737#comment-16318737
]
ASF subversion and git services commented on SOLR-11631:
Commit e3f3cdd0851b7b8d681eb1aa47141a4278e2289c in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e3f3cdd ]
SOLR-11631: fix Solrj tests
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317947#comment-16317947
]
Noble Paul commented on SOLR-11631:
---
[~varunthacker]it is not necessarily useful to a human user. However, it's
useful for a program to know what exception was thrown
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317563#comment-16317563
]
Steve Rowe commented on SOLR-11631:
---
bq. [...] the error key is not inside the responseHeader section, which seems
like the right place to me, since the error info is metadata, not data.
I'll make a different issue to consistently place this info across all Solr
APIs.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317561#comment-16317561
]
Steve Rowe commented on SOLR-11631:
---
{quote}
{noformat}
"metadata":[
"error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
"root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
{noformat}
In what cases will this part of the response be useful to users?
{quote}
[~varunthacker], I think this should go on another issue.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317558#comment-16317558
]
ASF subversion and git services commented on SOLR-11631:
Commit 34b30da60cc4b6f9ed0a528d470eb075871db6f7 in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=34b30da ]
SOLR-11631: The Schema API should return non-zero status when there are failures
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317559#comment-16317559
]
ASF subversion and git services commented on SOLR-11631:
Commit 9f221796fe1b79ead6509efdcaa0a17c5a382c65 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9f22179 ]
SOLR-11631: The Schema API should return non-zero status when there are failures
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch, SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250194#comment-16250194
]
Varun Thacker commented on SOLR-11631:
--
{code}
"metadata":[
"error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
"root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
{code}
In what cases will this part of the response be useful to users?
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250130#comment-16250130
]
Steve Rowe commented on SOLR-11631:
---
Your patch is definitely an improvement [~noble.paul].
With your patch, when I create a schemaless collection with {{bin/solr}} and
attempt to define the same field twice via {{curl -H 'application/json'
http://localhost:8983/solr/mycoll/schema -d '\{ add-field: \{ name: mynewfield,
type: string \}\}'}}, I get the following the second time:
{noformat}
{
"responseHeader":{
"status":400,
"QTime":2},
"error":{
"metadata":[
"error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
"root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
"details":[{
"add-field":{
"name":"mynewfield",
"type":"string"},
"errorMessages":["Field 'mynewfield' already exists.\n"]}],
"msg":"error processing commands",
"code":400}}
{noformat}
Which seems reasonable to me, with the exception that the {{error}} key is not
inside the {{responseHeader}} section, which seems like the right place to me,
since the error info is metadata, not data.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch, SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249030#comment-16249030
]
Noble Paul commented on SOLR-11631:
---
[~steve_rowe]
Let's see what we want to achieve.
# Errors should not return status=0 in response headers
# The error details key need to be standardized. We have errorMessages and
errors in different places
# Where to put the error key? as a separate kley or, within the
{{responseHeader}} object
The problem with all out v1 APIs was that we never returned a proper payload.
We threw exceptions and jetty returned some html errors which dod not have any
response header or anything. While designing V2 API we had to make the choice
of return proper payload for v2 apis but , v1 apis had to be back compatible.
So, we chose to keep V1 APIs to return in the old format.
We can make a wholesale change for the whole error handling thing. But let's
first decide on what is the appropriate format
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248771#comment-16248771
]
Steve Rowe commented on SOLR-11631:
---
bq. Similar issue... I'm creating a test in SOLR-11542 ... this request
completed without throwing an exception. So now I wrap this with {{ ...
response.get("errorMessages"); ... }} Which I think kinda sucks. Also notice
the inconsistency in names... "errorMessages" here whereas "errors" for schema
API.
+1 to fix the similar v2 api problem, should go on a different issue though I
think.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247778#comment-16247778
]
Jason Gerlowski commented on SOLR-11631:
Varun recently noticed this was an issue for a lot of errors-cases in the
Core-Admin APIs too (SOLR-11551). I wonder if there are any other APIs that
don't set the "status" field appropriately.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247686#comment-16247686
]
David Smiley commented on SOLR-11631:
-
Similar issue... I'm creating a test in SOLR-11542 which calls this:
{code:java}
solrClient.request(new V2Request.Builder("/collections/" + configName +
"/config/params")
.withMethod(SolrRequest.METHOD.POST)
.withPayload("{" +
" 'set' : {" +
"'_UPDATE' : {'processor':'inc,tolerant'}" +
" }" +
"}").build());
{code}
I originally messed up and used 'update' instead of 'set' in the JSON, and this
request completed without throwing an exception. So now I wrap this with:
{code:java}
private void checkNoError(NamedList response) {
Object errors = response.get("errorMessages");
assertNull("" + errors, errors);
}
{code}
Which I think kinda sucks. Also notice the inconsistency in names...
"errorMessages" here whereas "errors" for schema API.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247683#comment-16247683
]
Steve Rowe commented on SOLR-11631:
---
FYI TolerantUpdateProcessor puts the "errors" key in the responseHeader, and
*throws* an exception if maxErrors is exceeded.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247644#comment-16247644
]
Steve Rowe commented on SOLR-11631:
---
bq. I don't think we should throw SolrException . We should set appropriate
status in the responseHeader if an errors key is present
Why is the errors key in the response body instead of the responseHeader?
Seems sketchy to me to set status based on a body key that might be used for
things not related to status.
BTW at present the only way to set the status is via the response exception -
see {{SolrCore.postDecorateResponse()}}.
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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-11631) Schema API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-11631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247425#comment-16247425
]
Noble Paul commented on SOLR-11631:
---
I don't think we should throw {{SolrException}} . We should set appropriate
status in the responseHeader if an {{errors}} key is present
> Schema API always has status 0
> --
>
> Key: SOLR-11631
> URL: https://issues.apache.org/jira/browse/SOLR-11631
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
> Attachments: SOLR-11631.patch
>
>
> Schema API failures always return status=0.
> Consumers should be able to detect failure using normal mechanisms (i.e.
> status != 0) rather than having to parse the response for "errors". Right
> now if I attempt to {{add-field}} an already existing field, I get:
> {noformat}
> {responseHeader={status=0,QTime=XXX},errors=[{add-field={name=YYY, ...},
> errorMessages=[Field 'YYY' already exists.]}]}
> {noformat}
--
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
