If you want to translate battle-axe into "battle axe", note that the
correct method would be to introduce a phrase search with slop 0. The and
operator may also work in most cases but the word positions will be lost,
you get an more unprecise search for docs that contain "battle" and "axe"
anywhere in the field.
Jörg
On Tue, Nov 11, 2014 at 1:27 AM, Dave Reed <infinit...@gmail.com> wrote:
> Yes, and this was the key, thank you so much. But see my reply above about
> the docs on that param being confusing. That was really the source of the
> problem for me.
>
>
> On Monday, November 10, 2014 4:15:05 PM UTC-8, Amish Asthana wrote:
>>
>> 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/4d64842d-6374-465d-b261-452d845a3985%40googlegroups.com
> <https://groups.google.com/d/msgid/elasticsearch/4d64842d-6374-465d-b261-452d845a3985%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEwS3ZGs540HcpBipfa__Q8fjPRVkrrHCt0KXJpKn3a2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
