Java High Level REST Client - order of fields in document during saving and retrieval

Elastic Stack Elasticsearch
1

  1. Is the order of the saved document structure guaranteed in elasticsearch? Currently I see that it is, but I don't know if it's because of some default value of some option in the es-rest-client - generally I'd like to know what is the reason it is working :wink: Nevertheless apart of rest-client there could be still on elasticsearch site 'problem', when the order cannot be guaranteed by the database itself (or should be configured) - so does elasticsearch make maybe such guarantee?

  2. The structure of obtained document in Kibana is different, then the one retrieved by es-rest-client - is there a possibility to retrieve it 1:1 as it is in elasticsearch (so as it is displayed in Kibana) ?
    If it's not possible then, is maybe the order of an array guaranteed?

2

can you be more specific what order you are talking about? Is it the structure of the JSON document? That is not changed. However your serialization library (or the one frmo kibana) may freely chose how to serialize an object to JSON, as long as it is valid.

May I ask what the background is for this question? It seems that there is a question hidden beneath a question...

3

Thanks,

So one topic is clear.
Ths issue is that when I get doc via 'Java High Level REST Client' it's deserialization process changes the doc structure - so as you've written "your serialization library (or the one frmo kibana) may freely chose how to serialize an object to JSON, as long as it is valid.", so Kibana returns same object I've sent to index, f.e.:
INPUT doc:
{
"a": {
"aa": "1",
"aaa": "11"
},
"b": {
"bb": "2",
"bbb": "22"
}
}

--- Save doc in ES with Java_HL_REST_Client

OUTPUT doc visible in Kibana:

{
"a": {
"aa": "1",
"aaa": "11"
},
"b": {
"bb": "2",
"bbb": "22"
}
}

but OUTPUT doc returned by Java_HL_REST_Client, can be f.e. like this (actually it's object returned by getters of GetResponse, but just to show loosing the original doc structure) :
{
"b": {
"bb": "2",
"bbb": "22"
},
"a": {
"aaa": "11",
"aa": "1"
}
}
As you wrote "Is it the structure of the JSON document? That is not changed.", the question is now about the Java_HL_REST_Client. Can the deserializer by somehow controlled, so it does not change the structure of the doc? Seems like f.e. HashMap and not LinkedHashMap is used in deserialization.

4

as I said already, this depends on the components indexing and I would absolutely not worry about it. Can you explain, why this is an issue?

5

Let's say we have a service that sends object to be saved in elastic, this object contract is that the order of append(key,value) method invocation will be the order of elements on UI. We also don't know what will be put into append().
This contract was fulfilled till rest-client library change : io.searchbox.client.jest-client -> elasticsearch-rest-high-level-client. So now we are figuring out if we can somehow configure new rest-client or change structure of the object -> instead of a map an array of tuples, or some other solution.

6

can you share a code snippet how you are creating that JSON? If you are using the xcontent builder classes, this should not be an issue.

7

private final RestHighLevelClient elasticsearchClient;

public SearchTemplateResponse executeTemplateQuery(String query, Map<String, Object> scriptParams, String indexName) throws IOException {
    SearchTemplateRequest request = new SearchTemplateRequest();
    request.setRequest(new SearchRequest(indexName));
    request.setScriptType(ScriptType.INLINE);
    request.setScript(query);
    request.setScriptParams(scriptParams);
    return elasticsearchClient.searchTemplate(request, getRequestOptions());
}

SearchTemplateResponse searchResponse = executeTemplateQuery(query, queryParams, indexName);
return searchResponse.getResponse().toString();

// I also tried following, but searchResponse.getSource() is null , although response is available therefore we use searchResponse.getResponse().toString()
//
// Tuple<XContentType, Map<String, Object>> xContentTypeMapTuple = XContentHelper
// .convertToMap(searchResponse.getSource(), true, XContentType.JSON);
// Map<String, Object> stringObjectMap = xContentTypeMapTuple.v2();

8

Any chances to make progress on this? Can you maybe suggest to try some other approach? maybe with the low-level client?

9

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