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
I'm not using the standard analyzer, I'm using a pattern that will break
the text on all non-word characters, like this:
analyzer: {
letterordigit: {
type: pattern,
pattern: [^\\p{L}\\p{N}]+
}
}
I have verified that the message field is being broke up into the tokens I
Can you run the validate query output. That will be helpful.
amish
On Thursday, November 6, 2014 4:47:12 PM UTC-8, Dave Reed wrote:
I have a document with a field message, that contains the following text
(truncated):
Welcome to test.com!
The assertion field is mapped to have an analyzer
Yes of course :) Here we go:
{
- valid: true
- _shards: {
- total: 1
- successful: 1
- failed: 0
}
- explanations: [
- {
- index: index_v1
- valid: true
- explanation: message:welcome message:doesnotmatch
}
]
}
It
Also interesting... if I run the query with explain=true, I see information
in the details about the welcome token, but there's no mention at all
about the doesnotmatch token. I guess it wouldn't mention it though,
since if it did, the document shouldn't match in the first place.
On Monday,
I created a test index using your pattern and I am seeing the appropriate
behaviour.
I am assuming you are using the same analyzer for search/query as well as
ensuring that your DEFAULT OPERATOR is AND.
Note that using the welcome-doesnotmatchanything analzyzer will break into
two tokens with
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
Ok... specifying default_operator: AND worked
In that case, I'd like to say that the docs on that option are incomplete
or confusing. It says:
The default operator used if no explicit operator is specified. For example,
with a default operator of OR, the query capital of Hungary is
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
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
Hi Dave,
I think the reason is your message field using standard analyzer.
Standard analyzer divide text by -.
If you change analyzer to whitespace analyzer, it matches 0 documents.
_validate API is useful for checking exact query.
Example request:
curl -XGET /YOUR_INDEX/_validate/query?explain
11 matches
Mail list logo
