Re: order of the elements does matter?
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 ;-)
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+unsubscr...@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.
Re: order of the elements does matter?
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:
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'
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 ;-)
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
Re: order of the elements does matter?
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:
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'
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 ;-)
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
order of the elements does matter?
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+unsubscr...@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.
Re: order of the elements does matter?
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 (nchan...@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+unsubscr...@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+unsubscr...@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.
Re: order of the elements does matter?
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.comjavascript:)
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+unsubscr...@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.
Re: order of the elements does matter?
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+unsubscr...@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.
