Wrong results when using Java search, correct when REST


(Barak Yaish) #1

Hello,

I'm using 0.15.0-SNAPSHOT. I'm getting different results when querying
ES using JAVA/REST api. Correct results return when using the REST. I
tried different things, all returned the same. Can you please explain
what Am I doing wrong? For example:

XContentQueryBuilder xcqb = QueryBuilders.fieldQuery( "counter",
1016 );

response =
searchRequestBuilder.setSearchType( SearchType.DEFAULT ).setQuery( xcqb ).addFields( "runId",
"counter" ).setFrom( from ).setSize( 1000 ).execute().actionGet();

SearchHits hits = response.getHits();

for( SearchHit hit : hits )
{
String s = (String) hit.field( "runId" ).getValue();
Integer i = (Integer) hit.field( "counter" ).getValue(); // <---- i
not equal to 1016
}

When using REST, results are as expected:

[dmin@dev3 workspace]$ curl -XGET 'http://dev1:9200/1/record/_search?
q=hits:1016&pretty=true'
{
"took" : 42,
"timed_out" : false,
"_shards" : {
"total" : 10,
"successful" : 10,
"failed" : 0
},
"hits" : {
"total" : 2,
"max_score" : 1.0,
"hits" : [ {
"_index" : "1",
"_type" : "record",
"_id" : "13768",
"_version" : 1,
"_score" : 1.0, "_source" : {"runId":"uri_67214954","counter":
1016
}, {
"_index" : "1",
"_type" : "record",
"_id" : "19960",
"_version" : 1,
"_score" : 1.0, "_source" : {"runId":"uri_65333787","counter":
1016
}
}


(Shay Banon) #2

When you say not equal, what do you get? By default, you get the source back for each request (check teh getSource methods), unless you specify specific fields, in which case, if they are not stored, the source is loaded, parsed, and returns the relevant fields from it.
On Monday, January 31, 2011 at 1:24 PM, barak wrote:

Hello,

I'm using 0.15.0-SNAPSHOT. I'm getting different results when querying
ES using JAVA/REST api. Correct results return when using the REST. I
tried different things, all returned the same. Can you please explain
what Am I doing wrong? For example:

XContentQueryBuilder xcqb = QueryBuilders.fieldQuery( "counter",
1016 );

response =
searchRequestBuilder.setSearchType( SearchType.DEFAULT ).setQuery( xcqb ).addFields( "runId",
"counter" ).setFrom( from ).setSize( 1000 ).execute().actionGet();

SearchHits hits = response.getHits();

for( SearchHit hit : hits )
{
String s = (String) hit.field( "runId" ).getValue();
Integer i = (Integer) hit.field( "counter" ).getValue(); // <---- i
not equal to 1016
}

When using REST, results are as expected:

[dmin@dev3 workspace]$ curl -XGET 'http://dev1:9200/1/record/_search?
q=hits:1016&pretty=true'
{
"took" : 42,
"timed_out" : false,
"_shards" : {
"total" : 10,
"successful" : 10,
"failed" : 0
},
"hits" : {
"total" : 2,
"max_score" : 1.0,
"hits" : [ {
"_index" : "1",
"_type" : "record",
"_id" : "13768",
"_version" : 1,
"_score" : 1.0, "_source" : {"runId":"uri_67214954","counter":
1016
}, {
"_index" : "1",
"_type" : "record",
"_id" : "19960",
"_version" : 1,
"_score" : 1.0, "_source" : {"runId":"uri_65333787","counter":
1016
}
}


(Barak Yaish) #3

By not equal I mean I'm getting different values than the one I
specified in the query (1016 in the example above). I'm getting
results which do exist in the index, but not matching the query. So in
the example above the query specified docs which their counter is
1016, but the response return results which the counter field is other
than 1016, let's say 407 and runId xyz. Again a doc with counter =
407and runId = xyz indeed exist in the index, but I asked for docs
with counter = 1016...

The same query works well when using the REST api (i.e. the returned
docs contain only those their counter is equal to 1016). I'm guess I'm
doing something wrong with the JAVA api...

When you say not equal, what do you get? By default, you get the source back for each request (check teh getSource methods), unless you specify specific fields, in which case, if they are not stored, the source is loaded, parsed, and returns the relevant fields from it.

I did specify specific fields, so iterating the results with
for( SearchHit hit : hits ), hit.getSource() returns null. Data is
browsed by hit.field( ).getValue().


(Shay Banon) #4

Can you write a test that recreates it?
On Monday, January 31, 2011 at 11:31 PM, barak wrote:

By not equal I mean I'm getting different values than the one I
specified in the query (1016 in the example above). I'm getting
results which do exist in the index, but not matching the query. So in
the example above the query specified docs which their counter is
1016, but the response return results which the counter field is other
than 1016, let's say 407 and runId xyz. Again a doc with counter =
407and runId = xyz indeed exist in the index, but I asked for docs
with counter = 1016...

The same query works well when using the REST api (i.e. the returned
docs contain only those their counter is equal to 1016). I'm guess I'm
doing something wrong with the JAVA api...

When you say not equal, what do you get? By default, you get the source back for each request (check teh getSource methods), unless you specify specific fields, in which case, if they are not stored, the source is loaded, parsed, and returns the relevant fields from it.

I did specify specific fields, so iterating the results with
for( SearchHit hit : hits ), hit.getSource() returns null. Data is
browsed by hit.field( ).getValue().


(Barak Yaish) #5

I cleaned some of the code to create the test case, and the issue is
not occurring again... I'll check and report the findings.

Thanks.

On Jan 31, 11:35 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

Can you write a test that recreates it?

On Monday, January 31, 2011 at 11:31 PM, barak wrote:

By not equal I mean I'm getting different values than the one I
specified in the query (1016 in the example above). I'm getting
results which do exist in the index, but not matching the query. So in
the example above the query specified docs which their counter is
1016, but the response return results which the counter field is other
than 1016, let's say 407 and runId xyz. Again a doc with counter =
407and runId = xyz indeed exist in the index, but I asked for docs
with counter = 1016...

The same query works well when using the REST api (i.e. the returned
docs contain only those their counter is equal to 1016). I'm guess I'm
doing something wrong with the JAVA api...

When you say not equal, what do you get? By default, you get the source back for each request (check teh getSource methods), unless you specify specific fields, in which case, if they are not stored, the source is loaded, parsed, and returns the relevant fields from it.

I did specify specific fields, so iterating the results with
for( SearchHit hit : hits ), hit.getSource() returns null. Data is
browsed by hit.field( ).getValue().


(Shay Banon) #6

Cool, if you manage to recreate it, would love to fix it if its a problem. Thanks for the effort!
On Tuesday, February 1, 2011 at 12:22 AM, barak wrote:

I cleaned some of the code to create the test case, and the issue is
not occurring again... I'll check and report the findings.

Thanks.

On Jan 31, 11:35 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

Can you write a test that recreates it?

On Monday, January 31, 2011 at 11:31 PM, barak wrote:

By not equal I mean I'm getting different values than the one I
specified in the query (1016 in the example above). I'm getting
results which do exist in the index, but not matching the query. So in
the example above the query specified docs which their counter is
1016, but the response return results which the counter field is other
than 1016, let's say 407 and runId xyz. Again a doc with counter =
407and runId = xyz indeed exist in the index, but I asked for docs
with counter = 1016...

The same query works well when using the REST api (i.e. the returned
docs contain only those their counter is equal to 1016). I'm guess I'm
doing something wrong with the JAVA api...

When you say not equal, what do you get? By default, you get the source back for each request (check teh getSource methods), unless you specify specific fields, in which case, if they are not stored, the source is loaded, parsed, and returns the relevant fields from it.

I did specify specific fields, so iterating the results with
for( SearchHit hit : hits ), hit.getSource() returns null. Data is
browsed by hit.field( ).getValue().


(Barak Yaish) #7

It was my fault, I was reusing the SearchRequestBuilder returned by
client.prepareSearch( my-index ) (and which was set with different
options).. Sorry for all the noise :slight_smile:

On Feb 1, 12:23 am, Shay Banon shay.ba...@elasticsearch.com wrote:

Cool, if you manage to recreate it, would love to fix it if its a problem. Thanks for the effort!

On Tuesday, February 1, 2011 at 12:22 AM, barak wrote:

I cleaned some of the code to create the test case, and the issue is
not occurring again... I'll check and report the findings.

Thanks.

On Jan 31, 11:35 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

Can you write a test that recreates it?

On Monday, January 31, 2011 at 11:31 PM, barak wrote:

By not equal I mean I'm getting different values than the one I
specified in the query (1016 in the example above). I'm getting
results which do exist in the index, but not matching the query. So in
the example above the query specified docs which their counter is
1016, but the response return results which the counter field is other
than 1016, let's say 407 and runId xyz. Again a doc with counter =
407and runId = xyz indeed exist in the index, but I asked for docs
with counter = 1016...

The same query works well when using the REST api (i.e. the returned
docs contain only those their counter is equal to 1016). I'm guess I'm
doing something wrong with the JAVA api...

When you say not equal, what do you get? By default, you get the source back for each request (check teh getSource methods), unless you specify specific fields, in which case, if they are not stored, the source is loaded, parsed, and returns the relevant fields from it.

I did specify specific fields, so iterating the results with
for( SearchHit hit : hits ), hit.getSource() returns null. Data is
browsed by hit.field( ).getValue().


(system) #8