-
Notifications
You must be signed in to change notification settings - Fork 53
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
Allow updating enum values when referencing attribute #192
Comments
There's a need for this in open-telemetry/semantic-conventions#258. There's several attributes that are used in different metrics like
If these are defined as enums, when |
This seems like a bit of a hack to me and maybe a mis-use of "ref" to compensate for a lacking feature. Would it be better to first decouple the enum definition from the attribute definition and define a top-level "types" section alongside "groups"? |
would it mean that the same attribute would have different type for different conventions? Or that we'd need to introduce type inheritance? |
Both, I think 😃 |
BTW I believe enums being enums in code generation is a back-compat pain - when value is removed it breaks every lib that used it. I think they should be generated as maps instead of enums and then this issue can be resolved without type inheritance or type hell in strongly typed languages. for example, we have expandable enums (backed by a map) implementation in Azure SDKs, Here's an example in Java public final class CloudEventDataFormat extends ExpandableStringEnum<CloudEventDataFormat> {
public static final CloudEventDataFormat BYTES = fromString("BYTES", CloudEventDataFormat.class);
public static final CloudEventDataFormat JSON = fromString("JSON", CloudEventDataFormat.class);
public static CloudEventDataFormat fromString(String name) {
return super.fromString(name, CloudEventDataFormat.class);
}
} essentially it feels like an enum, but can create new instances of itself for unregistered strings. |
(or maybe we can introduce new |
That will be the case no matter how you implement code generation. You can at most make it a runtime error instead of a compile time error which would be bad anyways. Removing values from enums is not covered by our stability guarantees I think, but there is no sensible way to implement instrumentations so defensively that they would survive removal of an enum value they actually use without code changes. |
Watch me implement it in a sensible and back-compatible way: |
Another example is E.g. I'd like to be able to do something like - id: db
...
attributes:
- id: db.system
type:
members:
- id: cassandra
- id: mongodb
...
- id: mongodb
attributes:
- ref: db.system
type:
# some flag indicating that I don't want to extend everything?
members:
- ref: mongodb in this case I want only once value to be supported and not inherit all 50 values. |
Another use-case is the Ideally we want to define the |
Semantic conventions that reference a common attribute with an enum type, should be able to extend/overwrite the list of possible values.
E.g.
currently redeclaring a type is not supported.
While additional values could be documented in the note, md generation adds another note with possible values according to enum.
Related: open-telemetry/semantic-conventions#205
The text was updated successfully, but these errors were encountered: