Bug with minimum_number_should_match or is this incorrect usage?


(Diptamay) #1

Hi

I have this test data https://gist.github.com/661688, against which I
am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working (no
results) ones, I am just adding "minimum_number_should_match" : 1 to
the search clause:

  1. https://gist.github.com/661685 : has both the working and non-
    working version.
  2. https://gist.github.com/661680 : has both the working and non-
    working version. I understand in this specific query a "should" clause
    is not there but I would assume "minimum_number_should_match" should
    be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Shay Banon) #2

I am not sure I managed to understad whats not working and working since its
hard to understand if a certain query should match or not. If you set
minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not should
clauses, and set it to a higher value, then no doc will match. Is it not
working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay diptamay@gmail.com wrote:

Hi

I have this test data https://gist.github.com/661688, against which I
am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working (no
results) ones, I am just adding "minimum_number_should_match" : 1 to
the search clause:

  1. https://gist.github.com/661685 : has both the working and non-
    working version.
  2. https://gist.github.com/661680 : has both the working and non-
    working version. I understand in this specific query a "should" clause
    is not there but I would assume "minimum_number_should_match" should
    be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Diptamay) #3

If you look at the queries that I attached, the only difference is the
working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting results
to be returned when its set.

As an example, if one runs the queries in https://gist.github.com/661685,
the results from either should return only one document, whose id is
10990513, listed under https://gist.github.com/661688. However, only
one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set in
the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I am not sure I managed to understad whats not working and working since its
hard to understand if a certain query should match or not. If you set
minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not should
clauses, and set it to a higher value, then no doc will match. Is it not
working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com wrote:

Hi

I have this test datahttps://gist.github.com/661688, against which I
am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working (no
results) ones, I am just adding "minimum_number_should_match" : 1 to
the search clause:
1)https://gist.github.com/661685: has both the working and non-
working version.
2)https://gist.github.com/661680: has both the working and non-
working version. I understand in this specific query a "should" clause
is not there but I would assume "minimum_number_should_match" should
be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Shay Banon) #4

I think I manage to see what you mean, and it does seem strange (unless I am
missing something). Is there a chance that you can create a simple curl
recreation, with simpler docs (2-3 fields)? You can probably extract them
that from the relevant docs and then use similar/same question. I will have
a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay diptamay@gmail.com wrote:

If you look at the queries that I attached, the only difference is the
working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting results
to be returned when its set.

As an example, if one runs the queries in https://gist.github.com/661685,
the results from either should return only one document, whose id is
10990513, listed under https://gist.github.com/661688. However, only
one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set in
the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I am not sure I managed to understad whats not working and working since
its
hard to understand if a certain query should match or not. If you set
minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not should
clauses, and set it to a higher value, then no doc will match. Is it not
working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com wrote:

Hi

I have this test datahttps://gist.github.com/661688, against which I
am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working (no
results) ones, I am just adding "minimum_number_should_match" : 1 to
the search clause:
1)https://gist.github.com/661685: has both the working and non-
working version.
2)https://gist.github.com/661680: has both the working and non-
working version. I understand in this specific query a "should" clause
is not there but I would assume "minimum_number_should_match" should
be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Diptamay) #5

Yep, will do.

On Nov 3, 7:12 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I think I manage to see what you mean, and it does seem strange (unless I am
missing something). Is there a chance that you can create a simple curl
recreation, with simpler docs (2-3 fields)? You can probably extract them
that from the relevant docs and then use similar/same question. I will have
a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay dipta...@gmail.com wrote:

If you look at the queries that I attached, the only difference is the
working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting results
to be returned when its set.

As an example, if one runs the queries inhttps://gist.github.com/661685,
the results from either should return only one document, whose id is
10990513, listed underhttps://gist.github.com/661688. However, only
one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set in
the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I am not sure I managed to understad whats not working and working since
its
hard to understand if a certain query should match or not. If you set
minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not should
clauses, and set it to a higher value, then no doc will match. Is it not
working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com wrote:

Hi

I have this test datahttps://gist.github.com/661688, against which I
am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working (no
results) ones, I am just adding "minimum_number_should_match" : 1 to
the search clause:
1)https://gist.github.com/661685:has both the working and non-
working version.
2)https://gist.github.com/661680:has both the working and non-
working version. I understand in this specific query a "should" clause
is not there but I would assume "minimum_number_should_match" should
be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Diptamay) #6

Hi Shay

Please take checkout https://github.com/diptamay/es-issue

I have simplified the data quite a bit, though it isn't exactly 2-3
fields yet :). Please follow the readme to curl the data in and to run
the queries.

Thanks
Diptamay

On Nov 3, 7:12 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I think I manage to see what you mean, and it does seem strange (unless I am
missing something). Is there a chance that you can create a simple curl
recreation, with simpler docs (2-3 fields)? You can probably extract them
that from the relevant docs and then use similar/same question. I will have
a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay dipta...@gmail.com wrote:

If you look at the queries that I attached, the only difference is the
working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting results
to be returned when its set.

As an example, if one runs the queries inhttps://gist.github.com/661685,
the results from either should return only one document, whose id is
10990513, listed underhttps://gist.github.com/661688. However, only
one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set in
the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I am not sure I managed to understad whats not working and working since
its
hard to understand if a certain query should match or not. If you set
minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not should
clauses, and set it to a higher value, then no doc will match. Is it not
working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com wrote:

Hi

I have this test datahttps://gist.github.com/661688, against which I
am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working (no
results) ones, I am just adding "minimum_number_should_match" : 1 to
the search clause:
1)https://gist.github.com/661685:has both the working and non-
working version.
2)https://gist.github.com/661680:has both the working and non-
working version. I understand in this specific query a "should" clause
is not there but I would assume "minimum_number_should_match" should
be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Shay Banon) #7

Hi, ran the test, seems to work for me. This
https://github.com/diptamay/es-issue/blob/master/not_working.sh script,

The first curl search request returns a single result, which is good. And
matches the same one in matching. This is because the should clause does
produce a single match, so having it required by setting the minimum should
match to 1 is good.

the second one does not return a result, simply because there are no should
clauses, and you specify that there should be at least one that should
match, so, no results... .

(ran this on 0.12.1).

-shay.banon

On Thu, Nov 4, 2010 at 3:59 AM, diptamay diptamay@gmail.com wrote:

Hi Shay

Please take checkout https://github.com/diptamay/es-issue

I have simplified the data quite a bit, though it isn't exactly 2-3
fields yet :). Please follow the readme to curl the data in and to run
the queries.

Thanks
Diptamay

On Nov 3, 7:12 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I think I manage to see what you mean, and it does seem strange (unless I
am
missing something). Is there a chance that you can create a simple curl
recreation, with simpler docs (2-3 fields)? You can probably extract them
that from the relevant docs and then use similar/same question. I will
have
a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay dipta...@gmail.com wrote:

If you look at the queries that I attached, the only difference is the
working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting results
to be returned when its set.

As an example, if one runs the queries inhttps://
gist.github.com/661685,

the results from either should return only one document, whose id is
10990513, listed underhttps://gist.github.com/661688. However, only
one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set in
the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I am not sure I managed to understad whats not working and working
since

its

hard to understand if a certain query should match or not. If you set
minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not
should

clauses, and set it to a higher value, then no doc will match. Is it
not

working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com
wrote:

Hi

I have this test datahttps://gist.github.com/661688, against which
I

am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working
(no

results) ones, I am just adding "minimum_number_should_match" : 1
to

the search clause:
1)https://gist.github.com/661685:has both the working and non-
working version.
2)https://gist.github.com/661680:has both the working and non-
working version. I understand in this specific query a "should"
clause

is not there but I would assume "minimum_number_should_match"
should

be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Diptamay) #8

Hi

Don't know what to tell you :). This just wasn't working for me
yesterday. Today, the thing I did was delete my snapshots folder,
making this a completely clean run and it started working for me then
in the first run. Earlier, I was indexing/deleting/searching through
the REST api.

But then, I thought, how could I still reproduce it. So this is
reproducible, not consistently though. Please take the latest from
git@github.com:diptamay/es-issue.git
Then, run ./automate.sh
a) This will create an es-test index and load the sample data.
b) Then it fire ./not_working.sh to run the query which is not
working always.
c) It will then delete the documents.
This will run in an infinite loop, unless you stop it. You will see
that the search is inconsistent and sometimes it returns the results
and sometimes not.

Thanks for looking into it.

-Diptamay

On Nov 4, 5:10 am, Shay Banon shay.ba...@elasticsearch.com wrote:

Hi, ran the test, seems to work for me. Thishttps://github.com/diptamay/es-issue/blob/master/not_working.shscript,

The first curl search request returns a single result, which is good. And
matches the same one in matching. This is because the should clause does
produce a single match, so having it required by setting the minimum should
match to 1 is good.

the second one does not return a result, simply because there are no should
clauses, and you specify that there should be at least one that should
match, so, no results... .

(ran this on 0.12.1).

-shay.banon

On Thu, Nov 4, 2010 at 3:59 AM, diptamay dipta...@gmail.com wrote:

Hi Shay

Please take checkouthttps://github.com/diptamay/es-issue

I have simplified the data quite a bit, though it isn't exactly 2-3
fields yet :). Please follow the readme to curl the data in and to run
the queries.

Thanks
Diptamay

On Nov 3, 7:12 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I think I manage to see what you mean, and it does seem strange (unless I
am
missing something). Is there a chance that you can create a simple curl
recreation, with simpler docs (2-3 fields)? You can probably extract them
that from the relevant docs and then use similar/same question. I will
have
a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay dipta...@gmail.com wrote:

If you look at the queries that I attached, the only difference is the
working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting results
to be returned when its set.

As an example, if one runs the queries inhttps://
gist.github.com/661685,

the results from either should return only one document, whose id is
10990513, listed underhttps://gist.github.com/661688. However, only
one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set in
the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I am not sure I managed to understad whats not working and working
since

its

hard to understand if a certain query should match or not. If you set
minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not
should

clauses, and set it to a higher value, then no doc will match. Is it
not

working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com
wrote:

Hi

I have this test datahttps://gist.github.com/661688, against which
I

am running my test cases.

Here are the queries that I am firing. If you see the difference
between the working (returns results) versions and the non-working
(no

results) ones, I am just adding "minimum_number_should_match" : 1
to

the search clause:
1)https://gist.github.com/661685:hasboth the working and non-
working version.
2)https://gist.github.com/661680:hasboth the working and non-
working version. I understand in this specific query a "should"
clause

is not there but I would assume "minimum_number_should_match"
should

be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Shay Banon) #9

Hi,

Before I run it, have you factored in the fact that elasticsearch is near
real time? Can you try and execute a refresh before you search and see if it
happens?

-shay.banon

On Thu, Nov 4, 2010 at 5:15 PM, diptamay diptamay@gmail.com wrote:

Hi

Don't know what to tell you :). This just wasn't working for me
yesterday. Today, the thing I did was delete my snapshots folder,
making this a completely clean run and it started working for me then
in the first run. Earlier, I was indexing/deleting/searching through
the REST api.

But then, I thought, how could I still reproduce it. So this is
reproducible, not consistently though. Please take the latest from
git@github.com:diptamay/es-issue.git
Then, run ./automate.sh
a) This will create an es-test index and load the sample data.
b) Then it fire ./not_working.sh to run the query which is not
working always.
c) It will then delete the documents.
This will run in an infinite loop, unless you stop it. You will see
that the search is inconsistent and sometimes it returns the results
and sometimes not.

Thanks for looking into it.

-Diptamay

On Nov 4, 5:10 am, Shay Banon shay.ba...@elasticsearch.com wrote:

Hi, ran the test, seems to work for me. Thishttps://
github.com/diptamay/es-issue/blob/master/not_working.shscript,

The first curl search request returns a single result, which is good. And
matches the same one in matching. This is because the should clause does
produce a single match, so having it required by setting the minimum
should
match to 1 is good.

the second one does not return a result, simply because there are no
should
clauses, and you specify that there should be at least one that should
match, so, no results... .

(ran this on 0.12.1).

-shay.banon

On Thu, Nov 4, 2010 at 3:59 AM, diptamay dipta...@gmail.com wrote:

Hi Shay

Please take checkouthttps://github.com/diptamay/es-issue

I have simplified the data quite a bit, though it isn't exactly 2-3
fields yet :). Please follow the readme to curl the data in and to run
the queries.

Thanks
Diptamay

On Nov 3, 7:12 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I think I manage to see what you mean, and it does seem strange
(unless I

am

missing something). Is there a chance that you can create a simple
curl

recreation, with simpler docs (2-3 fields)? You can probably extract
them

that from the relevant docs and then use similar/same question. I
will

have

a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay dipta...@gmail.com
wrote:

If you look at the queries that I attached, the only difference is
the

working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting
results

to be returned when its set.

As an example, if one runs the queries inhttps://
gist.github.com/661685,

the results from either should return only one document, whose id
is

10990513, listed underhttps://gist.github.com/661688. However,
only

one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set
in

the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com
wrote:

I am not sure I managed to understad whats not working and
working

since

its

hard to understand if a certain query should match or not. If you
set

minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not
should

clauses, and set it to a higher value, then no doc will match. Is
it

not

working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com
wrote:

Hi

I have this test datahttps://gist.github.com/661688, against
which

I

am running my test cases.

Here are the queries that I am firing. If you see the
difference

between the working (returns results) versions and the
non-working

(no

results) ones, I am just adding "minimum_number_should_match" :
1

to

the search clause:
1)https://gist.github.com/661685:hasboth the working and non-
working version.
2)https://gist.github.com/661680:hasboth the working and non-
working version. I understand in this specific query a "should"
clause

is not there but I would assume "minimum_number_should_match"
should

be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Diptamay) #10

Hi

My bad. Sorry about that. Seems the refresh makes it work
consistently. Whats the default time set for the refresh to take
place?

Thanks
Diptamay

On Nov 4, 2:10 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

Hi,

Before I run it, have you factored in the fact that elasticsearch is near
real time? Can you try and execute a refresh before you search and see if it
happens?

-shay.banon

On Thu, Nov 4, 2010 at 5:15 PM, diptamay dipta...@gmail.com wrote:

Hi

Don't know what to tell you :). This just wasn't working for me
yesterday. Today, the thing I did was delete my snapshots folder,
making this a completely clean run and it started working for me then
in the first run. Earlier, I was indexing/deleting/searching through
the REST api.

But then, I thought, how could I still reproduce it. So this is
reproducible, not consistently though. Please take the latest from
g...@github.com:diptamay/es-issue.git
Then, run ./automate.sh
a) This will create an es-test index and load the sample data.
b) Then it fire ./not_working.sh to run the query which is not
working always.
c) It will then delete the documents.
This will run in an infinite loop, unless you stop it. You will see
that the search is inconsistent and sometimes it returns the results
and sometimes not.

Thanks for looking into it.

-Diptamay

On Nov 4, 5:10 am, Shay Banon shay.ba...@elasticsearch.com wrote:

Hi, ran the test, seems to work for me. Thishttps://
github.com/diptamay/es-issue/blob/master/not_working.shscript,

The first curl search request returns a single result, which is good. And
matches the same one in matching. This is because the should clause does
produce a single match, so having it required by setting the minimum
should
match to 1 is good.

the second one does not return a result, simply because there are no
should
clauses, and you specify that there should be at least one that should
match, so, no results... .

(ran this on 0.12.1).

-shay.banon

On Thu, Nov 4, 2010 at 3:59 AM, diptamay dipta...@gmail.com wrote:

Hi Shay

Please take checkouthttps://github.com/diptamay/es-issue

I have simplified the data quite a bit, though it isn't exactly 2-3
fields yet :). Please follow the readme to curl the data in and to run
the queries.

Thanks
Diptamay

On Nov 3, 7:12 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

I think I manage to see what you mean, and it does seem strange
(unless I

am

missing something). Is there a chance that you can create a simple
curl

recreation, with simpler docs (2-3 fields)? You can probably extract
them

that from the relevant docs and then use similar/same question. I
will

have

a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay dipta...@gmail.com
wrote:

If you look at the queries that I attached, the only difference is
the

working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting
results

to be returned when its set.

As an example, if one runs the queries inhttps://
gist.github.com/661685,

the results from either should return only one document, whose id
is

10990513, listed underhttps://gist.github.com/661688. However,
only

one of the queries (the working one) is returning the result, while
the resulting (or expected) document matches all the criteria set
in

the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com
wrote:

I am not sure I managed to understad whats not working and
working

since

its

hard to understand if a certain query should match or not. If you
set

minimum_number_should_match, it relates to the required number of
should/optional clauses that will have to match. If you have not
should

clauses, and set it to a higher value, then no doc will match. Is
it

not

working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com
wrote:

Hi

I have this test datahttps://gist.github.com/661688, against
which

I

am running my test cases.

Here are the queries that I am firing. If you see the
difference

between the working (returns results) versions and the
non-working

(no

results) ones, I am just adding "minimum_number_should_match" :
1

to

the search clause:
1)https://gist.github.com/661685:hasboththe working and non-
working version.
2)https://gist.github.com/661680:hasboththe working and non-
working version. I understand in this specific query a "should"
clause

is not there but I would assume "minimum_number_should_match"
should

be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(Shay Banon) #11

Its set by default to 1 second.

cheers,
-shay.banon

On Thu, Nov 4, 2010 at 8:32 PM, diptamay diptamay@gmail.com wrote:

Hi

My bad. Sorry about that. Seems the refresh makes it work
consistently. Whats the default time set for the refresh to take
place?

Thanks
Diptamay

On Nov 4, 2:10 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

Hi,

Before I run it, have you factored in the fact that elasticsearch is
near
real time? Can you try and execute a refresh before you search and see if
it
happens?

-shay.banon

On Thu, Nov 4, 2010 at 5:15 PM, diptamay dipta...@gmail.com wrote:

Hi

Don't know what to tell you :). This just wasn't working for me
yesterday. Today, the thing I did was delete my snapshots folder,
making this a completely clean run and it started working for me then
in the first run. Earlier, I was indexing/deleting/searching through
the REST api.

But then, I thought, how could I still reproduce it. So this is
reproducible, not consistently though. Please take the latest from
g...@github.com:diptamay/es-issue.git
Then, run ./automate.sh
a) This will create an es-test index and load the sample data.
b) Then it fire ./not_working.sh to run the query which is not
working always.
c) It will then delete the documents.
This will run in an infinite loop, unless you stop it. You will see
that the search is inconsistent and sometimes it returns the results
and sometimes not.

Thanks for looking into it.

-Diptamay

On Nov 4, 5:10 am, Shay Banon shay.ba...@elasticsearch.com wrote:

Hi, ran the test, seems to work for me. Thishttps://
github.com/diptamay/es-issue/blob/master/not_working.shscript,

The first curl search request returns a single result, which is good.
And

matches the same one in matching. This is because the should clause
does

produce a single match, so having it required by setting the minimum
should
match to 1 is good.

the second one does not return a result, simply because there are no
should
clauses, and you specify that there should be at least one that
should

match, so, no results... .

(ran this on 0.12.1).

-shay.banon

On Thu, Nov 4, 2010 at 3:59 AM, diptamay dipta...@gmail.com wrote:

Hi Shay

Please take checkouthttps://github.com/diptamay/es-issue

I have simplified the data quite a bit, though it isn't exactly 2-3
fields yet :). Please follow the readme to curl the data in and to
run

the queries.

Thanks
Diptamay

On Nov 3, 7:12 pm, Shay Banon shay.ba...@elasticsearch.com
wrote:

I think I manage to see what you mean, and it does seem strange
(unless I

am

missing something). Is there a chance that you can create a
simple

curl

recreation, with simpler docs (2-3 fields)? You can probably
extract

them

that from the relevant docs and then use similar/same question. I
will

have

a look at it tomorrow.

-shay.banon

On Thu, Nov 4, 2010 at 12:44 AM, diptamay dipta...@gmail.com
wrote:

If you look at the queries that I attached, the only difference
is

the

working and the non-working version is the presence
minimum_number_should_match and set to 1. Yes, I am expecting
results

to be returned when its set.

As an example, if one runs the queries inhttps://
gist.github.com/661685,

the results from either should return only one document, whose
id

is

10990513, listed underhttps://gist.github.com/661688. However,
only

one of the queries (the working one) is returning the result,
while

the resulting (or expected) document matches all the criteria
set

in

the non-working one as well.

-Diptamay

On Nov 3, 6:24 pm, Shay Banon shay.ba...@elasticsearch.com
wrote:

I am not sure I managed to understad whats not working and
working

since

its

hard to understand if a certain query should match or not. If
you

set

minimum_number_should_match, it relates to the required
number of

should/optional clauses that will have to match. If you have
not

should

clauses, and set it to a higher value, then no doc will
match. Is

it

not

working as expected?

On Wed, Nov 3, 2010 at 10:57 PM, diptamay <
dipta...@gmail.com>

wrote:

Hi

I have this test datahttps://gist.github.com/661688,
against

which

I

am running my test cases.

Here are the queries that I am firing. If you see the
difference

between the working (returns results) versions and the
non-working

(no

results) ones, I am just adding
"minimum_number_should_match" :

1

to

the search clause:
1)https://gist.github.com/661685:hasboththe working and
non-

working version.
2)https://gist.github.com/661680:hasboththe working and
non-

working version. I understand in this specific query a
"should"

clause

is not there but I would assume
"minimum_number_should_match"

should

be ignored here.

Is this a bug or am I missing something?

Thanks
Diptamay


(system) #12