Problems with "filtered"

Elastic Stack Elasticsearch
21

Yes, indeed when I start from a fresh copy of ES without any data,
PUT the mapping I want and PUT INDEX/TYPE/ID data with geoloc
consistent with the geo_point feature there is no more problem.
(I insist on the "consistent": if any geoloc insert is made of data
that generates an implicit mapping conflicting with what could be a
geo_point, then the problem appears again…)

However, the fact the in some situations (still to be reproduced) the
_bulk did not generated a default mapping and
then in that circumstance the "exists" on geoloc worked seems to
indicate that there is some minor detail that should be
either documented, either fixed.

Another point to think about is the fact that, when indeed "geoloc" is
not really a field,
(and let's forget about the geo_point context for the purpose here)
there is no easy way to test for different situations regarding the
presence of the structured field (empty or not)
and to test between "struct" : {}, "struct" : null, "struct" :
{ "field" : "defined" }

PS
When doing my regression gist, I made a copy-paste mistake that
reveals another problem:
I did by mistake a PUT on "INDEX/TYPE/_count" … which generates an
entry… now impossible (?) to delete.

On 12 fév, 17:04, Shay Banon shay.ba...@elasticsearch.com wrote:

This happens because the geoloc is not really a field in the document indexed, geoloc.lat and geoloc.lon are (and they are considered as simple numeric values, no geo features enabled). This happens because you did not specify that geoloc is if type "geo_point" in a mapping (that needs to be specified before indexing a doc). Once you do that, then it will work.

On Saturday, February 12, 2011 at 5:37 PM, P3 wrote:

Here is the gist

Test to demonstrate that filter with "exists" doesn't work correctly once an implicit mapping is created. · GitHub

22

If you can recreate the fact that bulk did not create explicit mapping, then I can have a look. Thats right, check for a "struct" using exists is not possible.
On Saturday, February 12, 2011 at 8:52 PM, P3 wrote:

Yes, indeed when I start from a fresh copy of ES without any data,
PUT the mapping I want and PUT INDEX/TYPE/ID data with geoloc
consistent with the geo_point feature there is no more problem.
(I insist on the "consistent": if any geoloc insert is made of data
that generates an implicit mapping conflicting with what could be a
geo_point, then the problem appears again…)

However, the fact the in some situations (still to be reproduced) the
_bulk did not generated a default mapping and
then in that circumstance the "exists" on geoloc worked seems to
indicate that there is some minor detail that should be
either documented, either fixed.

Another point to think about is the fact that, when indeed "geoloc" is
not really a field,
(and let's forget about the geo_point context for the purpose here)
there is no easy way to test for different situations regarding the
presence of the structured field (empty or not)
and to test between "struct" : {}, "struct" : null, "struct" :
{ "field" : "defined" }

PS
When doing my regression gist, I made a copy-paste mistake that
reveals another problem:
I did by mistake a PUT on "INDEX/TYPE/_count" … which generates an
entry… now impossible (?) to delete.

On 12 fév, 17:04, Shay Banon shay.ba...@elasticsearch.com wrote:

This happens because the geoloc is not really a field in the document indexed, geoloc.lat and geoloc.lon are (and they are considered as simple numeric values, no geo features enabled). This happens because you did not specify that geoloc is if type "geo_point" in a mapping (that needs to be specified before indexing a doc). Once you do that, then it will work.

On Saturday, February 12, 2011 at 5:37 PM, P3 wrote:

Here is the gist

Test to demonstrate that filter with "exists" doesn't work correctly once an implicit mapping is created. · GitHub