Is TEST a reserved keyword?

Hi there, today we run into an issue that took almost one hour to debug and
solve.

Like I posted on https://gist.github.com/4505957 , we had a really simple
schema, BUT one of the fields contained "TEST" as its value.
It wasn't possible to get a match from any queries.

The problem can be easily replicated in a new clean ElasticSearch
installation, I just downloaded the 0.20.2 from the web site.
I just started Elastic Search, created an index and put the two documents
as they are, with no mapping defined before the first PUT call.
If I change the value to "test", all works as expected and the result is
found.

I have this issue also with a 0.17.X version that I have on my notebook,
sorry I don't remember the second revision number.

I also had an issue some weeks ago with a field named "created_at" (we had
to change it to "creation_date"), probably it is the same problem.
If there are really some reserved words, please take some time to document
them.

Thanks for the attention

Emanuele

--

By default, you use a standard analyzer. So TEST is indexed as test.
A TermFilter is not analyzed. So ES is trying to compare TEST with test which is different.

Use a matchFilter (which is analyzed), change the analyzer to not analyzed or keyword analyzer, or search for test (as you did).

HTH

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 10 janv. 2013 à 22:46, Emanuele Massara emas80@gmail.com a écrit :

Hi there, today we run into an issue that took almost one hour to debug and solve.

Like I posted on https://gist.github.com/4505957 , we had a really simple schema, BUT one of the fields contained "TEST" as its value.
It wasn't possible to get a match from any queries.

The problem can be easily replicated in a new clean ElasticSearch installation, I just downloaded the 0.20.2 from the web site.
I just started Elastic Search, created an index and put the two documents as they are, with no mapping defined before the first PUT call.
If I change the value to "test", all works as expected and the result is found.

I have this issue also with a 0.17.X version that I have on my notebook, sorry I don't remember the second revision number.

I also had an issue some weeks ago with a field named "created_at" (we had to change it to "creation_date"), probably it is the same problem.
If there are really some reserved words, please take some time to document them.

Thanks for the attention

Emanuele

--

--

Hi, thanks for the reply.
It seems that I will have to configure better the collection, maybe setting
a mapping etc.
I have other problems with a field containing the "-" character.

The documentation on the web site is not so clear, all the examples are
very easy to replicate and it seems that much of the work is done by
ElasticSearch "magic".
I didn't found anything about upper and lowercases and "-", and created_at
of course.

Maybe you should add some sort of "better practices"

Thanks

Emanuele

On Friday, January 11, 2013 3:16:50 AM UTC+1, David Pilato wrote:

By default, you use a standard analyzer. So TEST is indexed as test.
A TermFilter is not analyzed. So ES is trying to compare TEST with test
which is different.

Use a matchFilter (which is analyzed), change the analyzer to not analyzed
or keyword analyzer, or search for test (as you did).

HTH

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 10 janv. 2013 à 22:46, Emanuele Massara <ema...@gmail.com <javascript:>>
a écrit :

Hi there, today we run into an issue that took almost one hour to debug
and solve.

Like I posted on https://gist.github.com/4505957 , we had a really simple
schema, BUT one of the fields contained "TEST" as its value.
It wasn't possible to get a match from any queries.

The problem can be easily replicated in a new clean ElasticSearch
installation, I just downloaded the 0.20.2 from the web site.
I just started Elastic Search, created an index and put the two documents
as they are, with no mapping defined before the first PUT call.
If I change the value to "test", all works as expected and the result is
found.

I have this issue also with a 0.17.X version that I have on my notebook,
sorry I don't remember the second revision number.

I also had an issue some weeks ago with a field named "created_at" (we had
to change it to "creation_date"), probably it is the same problem.
If there are really some reserved words, please take some time to document
them.

Thanks for the attention

Emanuele

--

--