Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark scripted_metric aggregation private in Serverless #2826

Open
pquentin opened this issue Aug 28, 2024 · 3 comments
Open

Mark scripted_metric aggregation private in Serverless #2826

pquentin opened this issue Aug 28, 2024 · 3 comments

Comments

@pquentin
Copy link
Member

🚀 Feature Proposal

The scripted_metric aggregation is now private in Elasticsearch Serverless. To reflect that in the specification, we need to:

  • Apply the @availability serverless visibility=private annotation to AggregationContainer
  • Extend the metamodel to allow availability annotations to types, and then apply@availability serverless visibility=private to the ScriptedMetricAggregate type
  • Update all generators to exclude types unavailable on Elasticsearch Serverless.
@flobernd
Copy link
Member

flobernd commented Aug 28, 2024

Hi @pquentin, this proposal contradicts our previous decision to only allow availability (as well as deprecation, etc.) on endpoints, properties, and enum members.

Allowing availability, deprecation, etc. on types causes all kinds of difficulties. We e.g. have the GeoPolygonQuery marked as deprecated at the moment, but the corresponding geo_polygon property in the QueryContainer is not marked accordingly.

What to do in these cases?

  1. Emit the property anyways as it seems to be available?
    > This causes a missing type error in the generated code, if we honor the deprecated annotation on the referenced type
  2. Always check for unavailable types and do not emit the property, if it references at least one?
    > Possible, but would require not only to look at the direct property type, but also recursively at all outgoing edges of the specific type (because, if the type or any referenced type of the type or any referenced type of any referenced type, etc. requires an unavailable type, we can not emit the property in this case).
  3. Add validations that ensure consistency of property availability in terms of type availability?
    > As well possible, but would require the exact same algorithm as in 2., but moves complexity to the schema compiler. Updating an availability annotation could potentially lead to thousands of side effects (places where the annotation must be updated for consistency).

We might be able to come up with a better solution here.

Related: #2643

@swallez
Copy link
Member

swallez commented Aug 29, 2024

Suggestion: name this property @union_availability for that information on types, to make it unambiguous that this applies to the usage of the type in the context of a union.

@flobernd
Copy link
Member

See #2830 for further details about @union_availability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants