# Elasticsearch 6.1.0 Java API search issues

**URL:** <https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581>\
**Category:** Elasticsearch\
**Created:** [December 29, 2017, 12:06pm UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581 "2017-12-29T12:06:14Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ajit\_Kumar](https://avatars.discourse-cdn.com/v4/letter/a/f475e1/32.png) [@Ajit\_Kumar](https://discuss.elastic.co/u/Ajit_Kumar)\
**Post date:** [December 29, 2017, 12:06pm UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581/1 "2017-12-29T12:06:14Z")

</div>

I am using ES - 6.1 and corresponding java version of the api. I was able to index the data using the java API. I validated this via kibana. All the mappings were correctly saved but an error comes up when I try to search. Even the most basic search returns me an empty collection.

```
// client is a reference to the TransportClient instance
SearchResponse searchResponse = this.client.prepareSearch(index).get().

```

When I try get the fields, by getFields() and further do a getField(key) I get a null pointer exception. I tried troubleshooting and saw that in the response there are no objects being returned. Following is the basic search I am doing.

```
// index is the index I am interested to search under.
SearchResponse searchResponse = this.client.prepareSearch(index).get();

```

This is an issue I see when I tried migrating my code to latest version from 1.7.3 Java API. Earlier, there are no issues found with our implementation.

Please help me out on this.

-Ajit

---

<div class="post-metadata">

**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\
**Post date:** [December 29, 2017, 7:05pm UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581/2 "2017-12-29T19:05:03Z")

</div>

I believe getFields() in 6.x will only return fields that have been  
explicitly set as stored. This behavior might have started in 2.x. Only the  
\_source field is stored and values can be retrieved from it. If you are  
retrieve multiple fields, you are better off just getting the source, which  
would require only one disk seek.

[https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-store.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-store.html)

---

<div class="post-metadata">

**Author:** ![Ajit\_Kumar](https://avatars.discourse-cdn.com/v4/letter/a/f475e1/32.png) [@Ajit\_Kumar](https://discuss.elastic.co/u/Ajit_Kumar)\
**Post date:** [December 30, 2017, 2:31am UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581/3 "2017-12-30T02:31:03Z")

</div>

Hi Ivan,

Thanks for that suggestion. I have re-indexed my data with each of the property set with stored mapping. I still do not get response with the fields I am interested in. The fields Keyset is still a null value

Following is the mapping sample.

```
"street": {
    "type": "text",
    "store": true
},
"country": {
    "type": "text",
    "store": true
},
"city": {
    "type": "text",
    "store": true
}

```

Here is response for each hit I get when I troubleshoot. I am getting the right number of hits in that index . Attaching the screenshot of my variables from debugger. **hits** is the variable containing response from following piece of code.

```
hits = searchResponse.getHits()

```

 ![53 AM](https://us1.discourse-cdn.com/elastic/original/3X/b/5/b59736c05a145e29d01b9ce8be77a28c2a6d0459.png)

Thank You for the help.

-Ajit

---

<div class="post-metadata">

**Author:** ![Ajit\_Kumar](https://avatars.discourse-cdn.com/v4/letter/a/f475e1/32.png) [@Ajit\_Kumar](https://discuss.elastic.co/u/Ajit_Kumar)\
**Post date:** [January 3, 2018, 11:26am UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581/4 "2018-01-03T11:26:10Z")

</div>

Hi All,

The issue is identified.

Unlike the previous versions, the new version will get the hits in a map in a different method.

```
//in previous version (1.7.3)
hit.getFields() 
// in new version (6.1.0)
hit.getSourceAsMap()

```

Further on, we can deserialize the response just the way we had been doing it earlier.

Thanks everyone for stopping and (hopefully) trying to solve the problem.

-Ajit

---

<div class="post-metadata">

**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\
**Post date:** [January 3, 2018, 9:12pm UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581/5 "2018-01-03T21:12:29Z")

</div>

Sorry if my suggestion did not work. Assumed that was the issue.

Getting the data from the source is not the same as getting it from the  
stored fields. In the majority of cases, it is the preferred way, so your  
new method should be ideal (it depends on the number/type of fields  
returned). You do not need to store the individual fields in your mapping  
if retrieving the fields from the source.

---

<div class="post-metadata">

**Author:** ![EricPSU](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ericpsu/32/21110_2.png) [@EricPSU](https://discuss.elastic.co/u/EricPSU)\
**Post date:** [January 19, 2018, 1:53pm UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581/6 "2018-01-19T13:53:21Z")

</div>

Thank you for this solution. We spent the better part of a day debugging this after an upgrade from 5.5.0 to 6.1.1. Has anyone been able to find specific documentation around this change?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [February 16, 2018, 1:53pm UTC](https://discuss.elastic.co/t/elasticsearch-6-1-0-java-api-search-issues/113581/7 "2018-02-16T13:53:31Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
