Add force_synthetic_source to mget#87574
Conversation
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
This adds the option to force synthetic source to the MGET API. See elastic#87068 for more discussion on why you'd want to do that - the short version is to get an upper bound on the performance cost of using synthetic source in MGET.
|
Pinging @elastic/clients-team (Team:Clients) |
romseygeek
left a comment
There was a problem hiding this comment.
One question re the public API, but LGTM otherwise.
| "description": "Should this request force synthetic _source? Use this to test if the mapping supports synthetic _source and to get a sense of the worst case performance. Fetches with this enabled will be slower the enabling synthetic source natively in the index.", | ||
| "visibility": "feature_flag", | ||
| "feature_flag": "es.index_mode_feature_flag_registered" | ||
| }, |
There was a problem hiding this comment.
I can't remember what we agreed here, didn't we suggest that we wouldn't document this at all so that it didn't appear as part of the 'official' API, but that Kibana or whoever could still use it by setting params explicitly on the underlying request?
There was a problem hiding this comment.
This is required for the tests to run. But the clients team is not picking it up - I think because of the feature_flag, but I'm not sure. I've talked with them. And with the kibana folks - they can use it without changes to the APIs.
And, yeah, I'm not documenting this in the asciidoc files. It's a debugging tool and anyone with the wherewithal to use it is probably also following the repo.
|
Pinging @elastic/es-distributed (Team:Distributed) |
This adds the option to force synthetic source to the MGET API. See
#87068 for more discussion on why you'd want to do that - the short
version is to get an upper bound on the performance cost of using
synthetic source in MGET.