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