No I am not saying that . I am saying this :
GET my_index_v1/mytype/_search
{
"query": {
"query_string": {
"default_field": "name",
"query": "welcome-doesnotmatchanything",
"default_operator": "AND"
}
}
}
Here I will not get a match as expected. If I do not specify then OR is the
deafult operator and it will match.
amish
On Monday, November 10, 2014 4:01:14 PM UTC-8, Dave Reed wrote:
>
> My default operator doesn't matter if I understand it correctly, because
> I'm specifying the operate explicitly. Also, I can reproduce this behavior
> using a single search term, so there's no operator to speak of. Unless
> you're saying that the default operator applies to a single term query if
> it is broken into tokens?
>
>
>> Note that using the welcome-doesnotmatchanything analzyzer will break
>> into two tokens with OR and your document will match unless you use AND
>
>
> This concerns me... my search looks like:
>
> message:welcome-doesnotmatchanything
>
> I cannot break that into an AND. The entire thing is a value provided by
> the end user. You're saying I should on the app side break the string they
> entered into tokens and join them with ANDs? That doesn't seem viable...
>
> Let me back up and say what I'm expecting the user to be able to do.
> There's a single text box where they can enter a search query, with the
> following rules:
> 1. The user may use a trailing wildcard, e.g. foo*
> 2. The user may enter multiple terms separated by a space. Only documents
> containing all of the terms will match.
> 3. The user might enter special characters, such as in "battle-axe",
> simply because that is what they think they should search for, which should
> match documents containing "battle" and "axe" (the same as a search for
> "battle axe").
>
> To that end, I am taking their search string and forming a search like
> this:
>
> message:<searchterm> AND...
>
> Where the string is split on spaces and joined with the AND clauses. For
> each individual part of the search phrase, I take care of escaping special
> characters (except "*" since I am allowing them to use wildcards). For
> example, if they entered "foo bar!", I would generate this query:
>
> message:foo AND message:bar\!
>
> The problem is they are entering "battle-axe", causing me to generate this:
>
> message:battle\-axe
>
> But that ends up being the same as:
>
> (message:battle OR message:axe)
>
> I guess that is what I was not expecting. Because of this behavior, I have
> to know from my app point of view what tokens I should be splitting the
> original string on, so that I can join them back together with ANDs. But
> that means basically reimplementing the tokenizer on my end, does it not?
> There must be a better way? Like specifying I want those terms to be joined
> with ANDs instead?
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/b20d4b80-2ebd-4b5c-a1e5-a434c2d68598%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
