Indeed. Even if I did tinker with these alternative query styles to avoid
syntax errors, there's other error scenarios to consider. What kind of
message and error structure could I expect for, say, a critical shard
failure? I'd still really like to know:
- What kind of error reports I can expect, and;
- What structure those reports will have.
I look at, say, C# .NET, where every library method has a clear definition
of what exception objects to expect, and in what scenarios. The
strongly-typed exception objects make it easy to gracefully handle
different errors -
File.Open Method (System.IO) | Microsoft Learn - If on
File.Open I get a FileNotFoundException, I can probably blame the user for
choosing an invalid file name. But if I get an IOException, I can probably
say "oh no, I think there might be a problem with your disk".
Or the Twitter REST API where response codes are all clearly defined within
the context of the API - Documentation Home | Docs | Twitter Developer Platform
The Twitter advertising API even has the good grace to provide an
errors/message node that *"will indicate a (usually) human-readable
description of the error in English" *-
https://dev.twitter.com/ads/campaigns/response-codes
But I can't find any equivalent documentation for Elasticsearch. The
closest I've come so far is this -
- "Elasticsearch returns an HTTP status code like 200 OK". From which I
might assume a full range of HTTP status codes is in use. But... y'know,
assumptions. And even with HTTP status codes, unless there's an
accompanying (concise) message, it's not easy to determine what's going on.
A 400 - Bad Request could mean bad query syntax, or it could mean the query
is specifying an index that doesn't exist. As an integrating application,
it would be my responsibility to notify the user that they've entered a
bad query, but it might be my responsibility to notify an admin in the
case of a missing index.
On 8 May 2015 at 01:03, David Pilato david@pilato.fr wrote:
Indeed. The only workaround I can see in addition to the one you found
with + is to set default_operator to AND
DELETE simple
PUT simple/test/1
{
"foo": "bar baz"
}
PUT simple/test/2
{
"foo": "bar boz"
}
GET simple/_search
{
"query": {
"simple_query_string": {
"query": "bar baz",
"fields": [ "foo" ],
"default_operator": "AND"
}
}
}
But that’s not exactly what you are looking for.
--
David Pilato - Developer | Evangelist
elastic.co http://elastic.co
@dadoonet https://twitter.com/dadoonet | @elasticsearchfr
https://twitter.com/elasticsearchfr | @scrutmydocs
https://twitter.com/scrutmydocs
Le 7 mai 2015 à 07:41, Jason snixtor@gmail.com a écrit :
"I think that AND might work as well with simple query string"
Tried just now. Doesn't work, it gets treated as a search term instead of
an operator, so is functionally equivalent to "and" in query_string. I
could try translating operators, but a truly robust implementation of
that is more work than I would have liked.
On 7 May 2015 at 15:35, David Pilato david@pilato.fr wrote:
No that's fine to keep this thread here.
Well with query_string you can also use +
I did not check but I think that AND might work as well with simple query
string. It's not?
David
Le 7 mai 2015 à 07:14, Snixtor snixtor@gmail.com a écrit :
Regarding the discussion forum, I noticed literally 1 minute after
posting this message. Should I duplicate this question in the forum? Can it
be moved from the discussion group into the forum? The "we have moved" FAQ
didn't address this matter of "transition".
Regarding simple_query_string, I'm not as fond of the syntax. My
application is transitioning from another text search system to
Elasticsearch, and the syntax of query_string is a closer match to what
users are familiar with. For example, query_string uses "AND", while
simple_query_string uses "+". For the user base, that's possibly a
bigger issue than big error messages.
On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote:
Try simple_query_string.
BTW we moved to https://discuss.elastic.co/
David
Le 7 mai 2015 à 06:56, Snixtor sni...@gmail.com a écrit :
I have an application allowing users to specify the "query" value of a
"query_string" query. If the user inputs invalid search syntax, e.g. their
search is only "AND" (an operator without any values), Elasticsearch
returns an exceedingly verbose error message with very
user-unfriendly text like "failed to execute phase" and "shard failure",
when what I really want is a simple user-friendly error like "Bad search
syntax". In this particular example, text within the
"QueryParsingException" sections is close to what I'm looking for.
QueryParsingException[[<index_name>] Failed to parse query [AND]]
But it's buried in a sea of text. I could parse out any text within the
QueryParsingException, but frankly that feels like reverse-engineering. Will
all queries with bad syntax have user-friendly error text like this
particular example? Is the most user-friendly message always likely to
appear within QueryParsingException? Are there other error scenarios I
might want to handle that don't even have a QueryParsingException?
I've been digging through Elasticsearch documentation for some
explanation of the kinds of errors I might expect and what format those
error messages will be in, but I'm coming up blank. For what it's worth,
I'm integrating using the .NET client NEST.
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr
https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com
https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr
https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CANsC95qOv5W%2BKJzhUTdHO49AQ8490ETcEiL3da6bQws5MG8eCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.