# How to simulate X-Opaque-Id semantics in Elasticsearch 5.3
**URL:** https://discuss.elastic.co/t/how-to-simulate-x-opaque-id-semantics-in-elasticsearch-5-3/217710
**Category:** Elasticsearch
**Created:** [February 4, 2020, 12:57am UTC](https://discuss.elastic.co/t/how-to-simulate-x-opaque-id-semantics-in-elasticsearch-5-3/217710 "2020-02-04T00:57:07Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@btiernay-o](https://discuss.elastic.co/u/btiernay-o)
#### Post date: [February 4, 2020, 12:57am UTC](https://discuss.elastic.co/t/how-to-simulate-x-opaque-id-semantics-in-elasticsearch-5-3/217710/1 "2020-02-04T00:57:08Z")
Are there any known ways to simulate the newer `X-Opaque-Id` semantics for `/_search` requests in older versions of Elasticsearch (specifically 5.3.x)?
One approach I considered is co-opting the `_name` field as described in [https://stackoverflow.com/questions/42844111/is-it-possible-to-put-a-comment-in-an-elasticsearch-query](https://stackoverflow.com/questions/42844111/is-it-possible-to-put-a-comment-in-an-elasticsearch-query) and [https://github.com/elastic/elasticsearch/issues/30576](https://github.com/elastic/elasticsearch/issues/30576). However, this approach doesn't work without disruption (requires at least one `bool` query) and likely has performance implications associated with `matched_queries` processing. Another approach I've thought might make sense is using `source.excludes` and including a bogus field that contains a correlation id that can be used for joining with external systems for the purposes of tracing (see [How to track user actions (process list)?](https://discuss.elastic.co/t/how-to-track-user-actions-process-list/185008/3) for similar in later versions).
Any ideas for improvements would be greatly appreciated!
---
### Author:  [@btiernay-o](https://discuss.elastic.co/u/btiernay-o)
#### Post date: [February 4, 2020, 4:15pm UTC](https://discuss.elastic.co/t/how-to-simulate-x-opaque-id-semantics-in-elasticsearch-5-3/217710/2 "2020-02-04T16:15:56Z")
For the benefit of future readers, I see there is another approach using `stats`:
> [@Passing requestId in ES logs](https://discuss.elastic.co/t/passing-requestid-in-es-logs/99498/4):
>
> Hi @animageofmine, stats groups are per request. You define them directly in your query. Copying the example that I gave in the other thread verbatim: GET /\_search { "query": { "match\_all": {} }, "stats" : ["myapplication"] } This will show up in the slow query log as: [2017-05-26 12:12:08,011][INFO][index.search.slowlog.fetch] [Elven] [old\_books][3] took[219.7micros], took\_millis[0], types[], stats[myapplication], search\_type[QUERY\_THEN\_FETCH], total\_shards[5], source[{…
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [February 4, 2020, 6:48pm UTC](https://discuss.elastic.co/t/how-to-simulate-x-opaque-id-semantics-in-elasticsearch-5-3/217710/3 "2020-02-04T18:48:08Z")
I think the best approach is to upgrade. 5.3.x [EOLed](https://www.elastic.co/support/eol) on September 28, 2018.
---
### Author:  [@btiernay-o](https://discuss.elastic.co/u/btiernay-o)
#### Post date: [February 6, 2020, 1:34pm UTC](https://discuss.elastic.co/t/how-to-simulate-x-opaque-id-semantics-in-elasticsearch-5-3/217710/4 "2020-02-06T13:34:44Z")
Agreed. Unfortunately that's not always viable, or may take some time and thus having an interim solution has a lot of value in our context.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [March 5, 2020, 1:34pm UTC](https://discuss.elastic.co/t/how-to-simulate-x-opaque-id-semantics-in-elasticsearch-5-3/217710/5 "2020-03-05T13:34:55Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.