Order of the elements does matter?

Elastic Stack Elasticsearch
1

Hi guys,

today I've noticed that order of the elements in the request does matter
for example:

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"sort" : {...},
"size" : 100,
"query" : {...}
}'

is working, while

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"query" : {...},
"sort" : {...},
"size" : 100
}'

Doesn't take effect of size as well as on sort.

I think the order shouldn't matter, and ES should reorder the elements
internally. Am I get it wrong, or there is special reason for this?

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c0d7791a-9c8a-40e9-855d-b6a88f2f2c87%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

2

Can you reproduce it with a full curl recreation and gist it?
In which version?

If confirmed, could you open an issue?

--
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet | @elasticsearchfr

Le 27 janvier 2014 at 18:50:32, Nikolay Chankov (nchankov@gmail.com) a écrit:

Hi guys,

today I've noticed that order of the elements in the request does matter for example:

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"sort" : {...},
"size" : 100,
"query" : {...}
}'

is working, while

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"query" : {...},
"sort" : {...},
"size" : 100
}'

Doesn't take effect of size as well as on sort.

I think the order shouldn't matter, and ES should reorder the elements internally. Am I get it wrong, or there is special reason for this?

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c0d7791a-9c8a-40e9-855d-b6a88f2f2c87%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/etPan.52e69d69.7c3dbd3d.b15f%40MacBook-Air-de-David.local.
For more options, visit https://groups.google.com/groups/opt_out.

3

I've noticed, that the "problem" came when in the request there is a
"filtered" node. Here is the full request:

curl-XGET 'http://localhost/search/_search' -d'{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size": 3,
"sort": [
{
"name.untouched": "asc"
}
]
}'

So, if it's called this way the sort and size are ignored, while if they
are placed above the query, they take effect, and I can see 3 records.
if it's not correct, I would expect to get an error, rather than ignoring
the params...

name is a multi_field with name.untouched is index not analyzed, object is
string, not analyzed. If it's still required I will try to create a full
gist tomorrow.

On Monday, January 27, 2014 5:54:48 PM UTC, David Pilato wrote:

Can you reproduce it with a full curl recreation and gist it?
In which version?

If confirmed, could you open an issue?

--
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet https://twitter.com/dadoonet | @elasticsearchfrhttps://twitter.com/elasticsearchfr

Le 27 janvier 2014 at 18:50:32, Nikolay Chankov (ncha...@gmail.com<javascript:>)
a écrit:

Hi guys,

today I've noticed that order of the elements in the request does matter
for example:

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"sort" : {...},
"size" : 100,
"query" : {...}
}'

is working, while

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"query" : {...},
"sort" : {...},
"size" : 100
}'

Doesn't take effect of size as well as on sort.

I think the order shouldn't matter, and ES should reorder the elements
internally. Am I get it wrong, or there is special reason for this?

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/c0d7791a-9c8a-40e9-855d-b6a88f2f2c87%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/efb884a7-2e0c-4194-82b3-c4b91f5f7751%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

Yes please. If you can gist a full curl recreation, that will help a lot!

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

Le 27 janv. 2014 à 19:36, Nikolay Chankov nchankov@gmail.com a écrit :

I've noticed, that the "problem" came when in the request there is a "filtered" node. Here is the full request:

curl-XGET 'http://localhost/search/_search' -d'{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size": 3,
"sort": [
{
"name.untouched": "asc"
}
]
}'

So, if it's called this way the sort and size are ignored, while if they are placed above the query, they take effect, and I can see 3 records.
if it's not correct, I would expect to get an error, rather than ignoring the params...

name is a multi_field with name.untouched is index not analyzed, object is string, not analyzed. If it's still required I will try to create a full gist tomorrow.

On Monday, January 27, 2014 5:54:48 PM UTC, David Pilato wrote:
Can you reproduce it with a full curl recreation and gist it?
In which version?

If confirmed, could you open an issue?

--
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet | @elasticsearchfr

Le 27 janvier 2014 at 18:50:32, Nikolay Chankov (ncha...@gmail.com) a écrit:

Hi guys,

today I've noticed that order of the elements in the request does matter for example:

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"sort" : {...},
"size" : 100,
"query" : {...}
}'

is working, while

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"query" : {...},
"sort" : {...},
"size" : 100
}'

Doesn't take effect of size as well as on sort.

I think the order shouldn't matter, and ES should reorder the elements internally. Am I get it wrong, or there is special reason for this?

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/c0d7791a-9c8a-40e9-855d-b6a88f2f2c87%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/efb884a7-2e0c-4194-82b3-c4b91f5f7751%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/2F527D28-62D9-468B-ABEA-7F5EED8ECBEF%40pilato.fr.
For more options, visit https://groups.google.com/groups/opt_out.

5

Since it's JSON, the order of the names does not matter. But to make it
nicer for humans to read, I have found that the LinkedHashMap and
LinkedHashSet classes to be nice drop-in replacements for their non-Linked
counterparts, have very little overhead, and have the nice property that
iterators return names in the same order in which they were added.

Of course, it's then necessary to add them in the same order each time, so
that the order is preserved! I've done the same thing with a generic Record
class that parses and writes the _source. It preserves the order of the
source fields, which is very nice for human readability (even though the
JSON remained correct without regard to order).

Hope this helps with some of the detail if/when you open an issue!

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b7449059-9c31-4428-8cbe-f8d5cb8b10e4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

6

Hi David,

Here is full gist:

curl -XDELETE 'http://localhost:9200/test_search'
curl -XPUT 'http://localhost:9200/test_search/' -d '
{
"mappings" : {
"record" : {
"properties" : {
"object" : {
"type" : "string",
"index" : "not_analyzed"
},
"name" : {
"type" : "string"
}
}
}
}
}
'
curl -XPUT 'http://localhost:9200/test_search/record/1' -d '{
"object" : "User",
"name" : "John Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/2' -d '{
"object" : "User",
"name" : "Jane Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/3' -d '{
"object" : "User",
"name" : "Joseph Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/4' -d '{
"object" : "User",
"name" : "Anna Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/5' -d '{
"object" : "Venue",
"name" : "Bar Luna"
}'

curl -XGET 'http://localhost:9200/test_search/_search?pretty=true' -d '{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size" : 2
}'

I've noticed that the problem exist only if under the top "query" node
there are 2 elements. If I remove "match_all" or "filtered" section the
size does take effect.
I've combined the examples in "And Filter" + "Term Filter" to create the
query, but probably this is the wrong way?

Thanks

On Monday, January 27, 2014 7:42:15 PM UTC, David Pilato wrote:

Yes please. If you can gist a full curl recreation, that will help a lot!

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

Le 27 janv. 2014 à 19:36, Nikolay Chankov <ncha...@gmail.com <javascript:>>
a écrit :

I've noticed, that the "problem" came when in the request there is a
"filtered" node. Here is the full request:

curl-XGET 'http://localhost/search/_search' -d'{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size": 3,
"sort": [
{
"name.untouched": "asc"
}
]
}'

So, if it's called this way the sort and size are ignored, while if they
are placed above the query, they take effect, and I can see 3 records.
if it's not correct, I would expect to get an error, rather than ignoring
the params...

name is a multi_field with name.untouched is index not analyzed, object is
string, not analyzed. If it's still required I will try to create a full
gist tomorrow.

On Monday, January 27, 2014 5:54:48 PM UTC, David Pilato wrote:

Can you reproduce it with a full curl recreation and gist it?
In which version?

If confirmed, could you open an issue?

--
David Pilato | Technical Advocate | Elasticsearch.com
http://Elasticsearch.com
@dadoonet https://twitter.com/dadoonet | @elasticsearchfrhttps://twitter.com/elasticsearchfr

Le 27 janvier 2014 at 18:50:32, Nikolay Chankov (ncha...@gmail.com) a
écrit:

Hi guys,

today I've noticed that order of the elements in the request does matter
for example:

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"sort" : {...},
"size" : 100,
"query" : {...}
}'

is working, while

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"query" : {...},
"sort" : {...},
"size" : 100
}'

Doesn't take effect of size as well as on sort.

I think the order shouldn't matter, and ES should reorder the elements
internally. Am I get it wrong, or there is special reason for this?

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/c0d7791a-9c8a-40e9-855d-b6a88f2f2c87%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/efb884a7-2e0c-4194-82b3-c4b91f5f7751%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3eebf7c1-8601-4e18-bfc3-68656da64e7b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

7

So the root cause is that your query is structured incorrectly. The
"match_all" should be inside of a "query" element, inside the "filtered"
query:

curl -XGET "http://localhost:9200/test_search/_search?pretty=true" -d'
{
"query": {
"filtered": {
"query" : {"match_all": {}},
"filter": {
"term": {
"object": "User"
}
}
}
},
"size" : 2
}'

Although this is technically a syntax error, it is very unfriendly of
Elasticsearch to not throw an exception and let you know. There is a PR to
fix this problem and it'll probably be merged soon:
Throw exception if an additional field was placed inside the "query" body by brwe · Pull Request #4913 · elastic/elasticsearch · GitHub

In the future Elasticsearch will throw an exception instead of silently
eating the error and giving strange results.

-Zach

On Tuesday, January 28, 2014 3:48:26 AM UTC-5, Nikolay Chankov wrote:

Hi David,

Here is full gist:

curl -XDELETE 'http://localhost:9200/test_search'
curl -XPUT 'http://localhost:9200/test_search/' -d '
{
"mappings" : {
"record" : {
"properties" : {
"object" : {
"type" : "string",
"index" : "not_analyzed"
},
"name" : {
"type" : "string"
}
}
}
}
}
'
curl -XPUT 'http://localhost:9200/test_search/record/1' -d '{
"object" : "User",
"name" : "John Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/2' -d '{
"object" : "User",
"name" : "Jane Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/3' -d '{
"object" : "User",
"name" : "Joseph Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/4' -d '{
"object" : "User",
"name" : "Anna Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/5' -d '{
"object" : "Venue",
"name" : "Bar Luna"
}'

curl -XGET 'http://localhost:9200/test_search/_search?pretty=true' -d '{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size" : 2
}'

I've noticed that the problem exist only if under the top "query" node
there are 2 elements. If I remove "match_all" or "filtered" section the
size does take effect.
I've combined the examples in "And Filter" + "Term Filter" to create the
query, but probably this is the wrong way?

Thanks

On Monday, January 27, 2014 7:42:15 PM UTC, David Pilato wrote:

Yes please. If you can gist a full curl recreation, that will help a lot!

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

Le 27 janv. 2014 à 19:36, Nikolay Chankov ncha...@gmail.com a écrit :

I've noticed, that the "problem" came when in the request there is a
"filtered" node. Here is the full request:

curl-XGET 'http://localhost/search/_search' -d'{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size": 3,
"sort": [
{
"name.untouched": "asc"
}
]
}'

So, if it's called this way the sort and size are ignored, while if they
are placed above the query, they take effect, and I can see 3 records.
if it's not correct, I would expect to get an error, rather than ignoring
the params...

name is a multi_field with name.untouched is index not analyzed, object
is string, not analyzed. If it's still required I will try to create a full
gist tomorrow.

On Monday, January 27, 2014 5:54:48 PM UTC, David Pilato wrote:

Can you reproduce it with a full curl recreation and gist it?
In which version?

If confirmed, could you open an issue?

--
David Pilato | Technical Advocate | Elasticsearch.com
http://Elasticsearch.com
@dadoonet https://twitter.com/dadoonet | @elasticsearchfrhttps://twitter.com/elasticsearchfr

Le 27 janvier 2014 at 18:50:32, Nikolay Chankov (ncha...@gmail.com) a
écrit:

Hi guys,

today I've noticed that order of the elements in the request does matter
for example:

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"sort" : {...},
"size" : 100,
"query" : {...}
}'

is working, while

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"query" : {...},
"sort" : {...},
"size" : 100
}'

Doesn't take effect of size as well as on sort.

I think the order shouldn't matter, and ES should reorder the elements
internally. Am I get it wrong, or there is special reason for this?

Thanks in advance.

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/c0d7791a-9c8a-40e9-855d-b6a88f2f2c87%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/efb884a7-2e0c-4194-82b3-c4b91f5f7751%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/89c510a0-df13-4d07-998d-f3dafee5e47f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

8

Thanks got clarification Zachary,

I was expected an exception too. Anyway, I need to change my query.

Thanks for your help guys!

On Tuesday, January 28, 2014 12:28:20 PM UTC, Zachary Tong wrote:

So the root cause is that your query is structured incorrectly. The
"match_all" should be inside of a "query" element, inside the "filtered"
query:

curl -XGET "http://localhost:9200/test_search/_search?pretty=true" -d'
{
"query": {
"filtered": {
"query" : {"match_all": {}},
"filter": {
"term": {
"object": "User"
}
}
}
},
"size" : 2
}'

Although this is technically a syntax error, it is very unfriendly of
Elasticsearch to not throw an exception and let you know. There is a PR to
fix this problem and it'll probably be merged soon:
Throw exception if an additional field was placed inside the "query" body by brwe · Pull Request #4913 · elastic/elasticsearch · GitHub

In the future Elasticsearch will throw an exception instead of silently
eating the error and giving strange results.

-Zach

On Tuesday, January 28, 2014 3:48:26 AM UTC-5, Nikolay Chankov wrote:

Hi David,

Here is full gist:

curl -XDELETE 'http://localhost:9200/test_search'
curl -XPUT 'http://localhost:9200/test_search/' -d '
{
"mappings" : {
"record" : {
"properties" : {
"object" : {
"type" : "string",
"index" : "not_analyzed"
},
"name" : {
"type" : "string"
}
}
}
}
}
'
curl -XPUT 'http://localhost:9200/test_search/record/1' -d '{
"object" : "User",
"name" : "John Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/2' -d '{
"object" : "User",
"name" : "Jane Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/3' -d '{
"object" : "User",
"name" : "Joseph Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/4' -d '{
"object" : "User",
"name" : "Anna Doe"
}'
curl -XPUT 'http://localhost:9200/test_search/record/5' -d '{
"object" : "Venue",
"name" : "Bar Luna"
}'

curl -XGET 'http://localhost:9200/test_search/_search?pretty=true' -d '{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size" : 2
}'

I've noticed that the problem exist only if under the top "query" node
there are 2 elements. If I remove "match_all" or "filtered" section the
size does take effect.
I've combined the examples in "And Filter" + "Term Filter" to create the
query, but probably this is the wrong way?

Thanks

On Monday, January 27, 2014 7:42:15 PM UTC, David Pilato wrote:

Yes please. If you can gist a full curl recreation, that will help a lot!

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

Le 27 janv. 2014 à 19:36, Nikolay Chankov ncha...@gmail.com a écrit :

I've noticed, that the "problem" came when in the request there is a
"filtered" node. Here is the full request:

curl-XGET 'http://localhost/search/_search' -d'{
"query": {
"match_all": {},
"filtered": {
"filter": {
"term": {
"object": "User"
}
}
}
},
"size": 3,
"sort": [
{
"name.untouched": "asc"
}
]
}'

So, if it's called this way the sort and size are ignored, while if they
are placed above the query, they take effect, and I can see 3 records.
if it's not correct, I would expect to get an error, rather than
ignoring the params...

name is a multi_field with name.untouched is index not analyzed, object
is string, not analyzed. If it's still required I will try to create a full
gist tomorrow.

On Monday, January 27, 2014 5:54:48 PM UTC, David Pilato wrote:

Can you reproduce it with a full curl recreation and gist it?
In which version?

If confirmed, could you open an issue?

--
David Pilato | Technical Advocate | Elasticsearch.com
http://Elasticsearch.com
@dadoonet https://twitter.com/dadoonet | @elasticsearchfrhttps://twitter.com/elasticsearchfr

Le 27 janvier 2014 at 18:50:32, Nikolay Chankov (ncha...@gmail.com) a
écrit:

Hi guys,

today I've noticed that order of the elements in the request does
matter for example:

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"sort" : {...},
"size" : 100,
"query" : {...}
}'

is working, while

curl -XGET 'http://localhost:9200/search/_search'-d '
{
"query" : {...},
"sort" : {...},
"size" : 100
}'

Doesn't take effect of size as well as on sort.

I think the order shouldn't matter, and ES should reorder the elements
internally. Am I get it wrong, or there is special reason for this?

Thanks in advance.

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/c0d7791a-9c8a-40e9-855d-b6a88f2f2c87%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/efb884a7-2e0c-4194-82b3-c4b91f5f7751%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/2829a087-0a49-4f92-891d-2f4e911a14fe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.