elastic
ESQL: Views REST API
This is extracted from the Views Prototype at https://github.com/elastic/elasticsearch/pull/134995 and is originally based on the "ESQL: View" prototype by Nik but with the following changes:
- No ES|QL language integration, only REST API for adding/removing and managing Views in cluster state
- ViewMetadata now inside ProjectMetadata
- NodeFeature to ensure metadata only exists in clusters fully upgraded
- Wide CRUD support (add, update, delete, list)
- View name validation
- View count, length and depth restrictions
The REST API looks like:
PUT _query/view/critical_service_errors_v {"query":"FROM ..."}
DELETE _query/view/critical_service_errors_v
GET _query/view/critical_service_errors_v
GET _query/view
Checklist:
- [x] Extract REST API from views prototype
- [x] Remove
listinterface and generalise GET command to cover list use cases (more in-line with other APIs) - [x] Verify that snapshot-only really blocks registration of REST API
- [x] Consider switching to use feature flags (instead of snapshot-only)
- [x] Consider dropping one of NodeFeature or TransportVersion since they cover the same requirement
- [x] Implement batched tasks, probably using
SequentialAckingBatchedTaskExecutor - [x] Stop using
ProjectResolverand instead use theProjectIDas is done in Enrich REST API - [x] Change ViewMetadata from a Map of name to View to instead be an array of View (which should contain the name)
Since these don't yet do anything, and will be part of multiple PRs before the feature is fully-fleshed out, I think it would be helpful for these to be behind a feature flag, so that they are not inadvertently released-and-then-changed.
Since these don't yet do anything, and will be part of multiple PRs before the feature is fully-fleshed out, I think it would be helpful for these to be behind a feature flag, so that they are not inadvertently released-and-then-changed.
We've made this SNAPSHOT only, which is essentially the same as a feature flag, and is the approach normally taken in the ES|QL team for cases like this where we do not yet want the feature to be released. However, I will add more tests that explicitly assert that the feature is missing outside of SNAPSHOT builds.
We've made this SNAPSHOT only, which is essentially the same as a feature flag, and is the approach normally taken in the ES|QL team for cases like this where we do not yet want the feature to be released. However, I will add more tests that explicitly assert that the feature is missing outside of SNAPSHOT builds.
As I read this, that is for the implementation itself, but does not prevent the REST APIs from being registered and available, even without the node feature. Unless I am misunderstanding it?
(Another drive-by comment, but this is not a full review)
Why do we have both a "get" and "list" action/API for these? All of our other APIs that follow this model register a single get REST handler that takes an optional {name} parameter, returning all the <things> when the {name} is missing.
I've added some comments for this. One thing that I don't see at all is the overlap checks to ensure that we do not create a view that has the same name as an index, alias, data stream, or data stream alias.
The plan was to do that in a separate PR, with checks in both directions. We are hoping to break this work down, where possible.