# Order of the elements does matter? **URL:** \ **Category:** Elasticsearch\ **Created:** [January 27, 2014, 5:50pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436 "2014-01-27T17:50:28Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Nikolay\_Chankov](https://avatars.discourse-cdn.com/v4/letter/n/a8b319/32.png) [@Nikolay\_Chankov](https://discuss.elastic.co/u/Nikolay_Chankov)\ **Post date:** [January 27, 2014, 5:50pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/1 "2014-01-27T17:50:28Z")
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](http://localhost:9200/search/_search'-d) ' { "sort" : {...}, "size" : 100, "query" : {...} }' is working, while curl -XGET '[http://localhost:9200/search/\_search'-d](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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [January 27, 2014, 5:54pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/2 "2014-01-27T17:54:48Z")
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 | @elasticsearchfr Le 27 janvier 2014 at 18:50:32, Nikolay Chankov ([nchankov@gmail.com](mailto: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](http://localhost:9200/search/_search'-d) ' { "sort" : {...}, "size" : 100, "query" : {...} }' is working, while curl -XGET '[http://localhost:9200/search/\_search'-d](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](mailto: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](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](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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![Nikolay\_Chankov](https://avatars.discourse-cdn.com/v4/letter/n/a8b319/32.png) [@Nikolay\_Chankov](https://discuss.elastic.co/u/Nikolay_Chankov)\ **Post date:** [January 27, 2014, 6:36pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/3 "2014-01-27T18:36:29Z")
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](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](https://twitter.com/dadoonet) | @elasticsearchfr[https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) > > Le 27 janvier 2014 at 18:50:32, Nikolay Chankov ([ncha...@gmail.com](mailto: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](http://localhost:9200/search/_search'-d) ' > { > "sort" : {...}, > "size" : 100, > "query" : {...} > }' > > is working, while > > curl -XGET '[http://localhost:9200/search/\_search'-d](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](mailto: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](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](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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [January 27, 2014, 7:42pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/4 "2014-01-27T19:42:15Z")
Yes please. If you can gist a full curl recreation, that will help a lot! -- David 😉 Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs Le 27 janv. 2014 à 19:36, Nikolay Chankov [nchankov@gmail.com](mailto: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](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 | @elasticsearchfr > > Le 27 janvier 2014 at 18:50:32, Nikolay Chankov ([ncha...@gmail.com](mailto: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](http://localhost:9200/search/_search'-d) ' > > { > > "sort" : {...}, > > "size" : 100, > > "query" : {...} > > }' > > > > is working, while > > > > curl -XGET '[http://localhost:9200/search/\_search'-d](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](mailto: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](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](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](mailto: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](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](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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [January 27, 2014, 7:50pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/5 "2014-01-27T19:50:43Z")
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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![Nikolay\_Chankov](https://avatars.discourse-cdn.com/v4/letter/n/a8b319/32.png) [@Nikolay\_Chankov](https://discuss.elastic.co/u/Nikolay_Chankov)\ **Post date:** [January 28, 2014, 8:48am UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/6 "2014-01-28T08:48:26Z")
Hi David, Here is full gist: curl -XDELETE '[http://localhost:9200/test\_search](http://localhost:9200/test_search)' curl -XPUT '[http://localhost:9200/test\_search/](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](http://localhost:9200/test_search/record/1)' -d '{ "object" : "User", "name" : "John Doe" }' curl -XPUT '[http://localhost:9200/test\_search/record/2](http://localhost:9200/test_search/record/2)' -d '{ "object" : "User", "name" : "Jane Doe" }' curl -XPUT '[http://localhost:9200/test\_search/record/3](http://localhost:9200/test_search/record/3)' -d '{ "object" : "User", "name" : "Joseph Doe" }' curl -XPUT '[http://localhost:9200/test\_search/record/4](http://localhost:9200/test_search/record/4)' -d '{ "object" : "User", "name" : "Anna Doe" }' curl -XPUT '[http://localhost:9200/test\_search/record/5](http://localhost:9200/test_search/record/5)' -d '{ "object" : "Venue", "name" : "Bar Luna" }' curl -XGET '[http://localhost:9200/test\_search/\_search?pretty=true](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 😉 > Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs > > Le 27 janv. 2014 à 19:36, Nikolay Chankov \<[ncha...@gmail.com](mailto: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](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) > > [http://Elasticsearch.com](http://Elasticsearch.com)_ > > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr[https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) > > > > Le 27 janvier 2014 at 18:50:32, Nikolay Chankov ([ncha...@gmail.com](mailto: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](http://localhost:9200/search/_search'-d) ' > > { > > "sort" : {...}, > > "size" : 100, > > "query" : {...} > > }' > > > > is working, while > > > > curl -XGET '[http://localhost:9200/search/\_search'-d](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](mailto: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](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](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](mailto: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](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](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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\ **Post date:** [January 28, 2014, 12:28pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/7 "2014-01-28T12:28:20Z")
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](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](https://github.com/elasticsearch/elasticsearch/pull/4913) 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](http://localhost:9200/test_search)' > curl -XPUT '[http://localhost:9200/test\_search/](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](http://localhost:9200/test_search/record/1)' -d '{ > "object" : "User", > "name" : "John Doe" > }' > curl -XPUT '[http://localhost:9200/test\_search/record/2](http://localhost:9200/test_search/record/2)' -d '{ > "object" : "User", > "name" : "Jane Doe" > }' > curl -XPUT '[http://localhost:9200/test\_search/record/3](http://localhost:9200/test_search/record/3)' -d '{ > "object" : "User", > "name" : "Joseph Doe" > }' > curl -XPUT '[http://localhost:9200/test\_search/record/4](http://localhost:9200/test_search/record/4)' -d '{ > "object" : "User", > "name" : "Anna Doe" > }' > curl -XPUT '[http://localhost:9200/test\_search/record/5](http://localhost:9200/test_search/record/5)' -d '{ > "object" : "Venue", > "name" : "Bar Luna" > }' > > curl -XGET '[http://localhost:9200/test\_search/\_search?pretty=true](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 😉 > > Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs > > > > Le 27 janv. 2014 à 19:36, Nikolay Chankov [ncha...@gmail.com](mailto: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](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) > > > [http://Elasticsearch.com](http://Elasticsearch.com)_ > > > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr[https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) > > > > > > Le 27 janvier 2014 at 18:50:32, Nikolay Chankov ([ncha...@gmail.com](mailto: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](http://localhost:9200/search/_search'-d) ' > > > { > > > "sort" : {...}, > > > "size" : 100, > > > "query" : {...} > > > }' > > > > > > is working, while > > > > > > curl -XGET '[http://localhost:9200/search/\_search'-d](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](mailto: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](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](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](mailto: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](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](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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![Nikolay\_Chankov](https://avatars.discourse-cdn.com/v4/letter/n/a8b319/32.png) [@Nikolay\_Chankov](https://discuss.elastic.co/u/Nikolay_Chankov)\ **Post date:** [January 28, 2014, 1:00pm UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/8 "2014-01-28T13:00:07Z")
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](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](https://github.com/elasticsearch/elasticsearch/pull/4913) > > 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](http://localhost:9200/test_search)' > > curl -XPUT '[http://localhost:9200/test\_search/](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](http://localhost:9200/test_search/record/1)' -d '{ > > "object" : "User", > > "name" : "John Doe" > > }' > > curl -XPUT '[http://localhost:9200/test\_search/record/2](http://localhost:9200/test_search/record/2)' -d '{ > > "object" : "User", > > "name" : "Jane Doe" > > }' > > curl -XPUT '[http://localhost:9200/test\_search/record/3](http://localhost:9200/test_search/record/3)' -d '{ > > "object" : "User", > > "name" : "Joseph Doe" > > }' > > curl -XPUT '[http://localhost:9200/test\_search/record/4](http://localhost:9200/test_search/record/4)' -d '{ > > "object" : "User", > > "name" : "Anna Doe" > > }' > > curl -XPUT '[http://localhost:9200/test\_search/record/5](http://localhost:9200/test_search/record/5)' -d '{ > > "object" : "Venue", > > "name" : "Bar Luna" > > }' > > > > curl -XGET '[http://localhost:9200/test\_search/\_search?pretty=true](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 😉 > > > Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs > > > > > > Le 27 janv. 2014 à 19:36, Nikolay Chankov [ncha...@gmail.com](mailto: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](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) > > > > [http://Elasticsearch.com](http://Elasticsearch.com)_ > > > > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr[https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) > > > > > > > > Le 27 janvier 2014 at 18:50:32, Nikolay Chankov ([ncha...@gmail.com](mailto: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](http://localhost:9200/search/_search'-d) ' > > > > { > > > > "sort" : {...}, > > > > "size" : 100, > > > > "query" : {...} > > > > }' > > > > > > > > is working, while > > > > > > > > curl -XGET '[http://localhost:9200/search/\_search'-d](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](mailto: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](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](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](mailto: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](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](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](mailto: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](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](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:54am UTC](https://discuss.elastic.co/t/order-of-the-elements-does-matter/15436/9 "2017-07-06T01:54:26Z")