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
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
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.
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).
On Thu, Nov 4, 2010 at 3:59 AM, diptamay dipta...@gmail.com wrote:
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
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
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
a look at it tomorrow.
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://
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.
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
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
clauses, and set it to a higher value, then no doc will match. Is it
working as expected?
On Wed, Nov 3, 2010 at 10:57 PM, diptamay dipta...@gmail.com
I have this test datahttps://gist.github.com/661688, against which
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
results) ones, I am just adding "minimum_number_should_match" : 1
the search clause:
1)https://gist.github.com/661685:hasboth the working and non-
2)https://gist.github.com/661680:hasboth the working and non-
working version. I understand in this specific query a "should"
is not there but I would assume "minimum_number_should_match"
be ignored here.
Is this a bug or am I missing something?