default to Unit.UNRECOGNIZED if unit is not present in Enum. #120
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The SDK currently uses an Enum to map Metric Unit types. If an unrecognized Unit type is returned during a call (such as 1dt.metrics.list()1), the result is a ValueError. I initially documented this in issue #116 .
In reality, our Dynatrace tenant contains numerous metric unit types that are not in that list. They come from us (custom metrics), extensions, etc., and I would assume this is common across customers. In its current state, it's not possible to pull a list of metrics from Dynatrace due to this error without hacking the SDK locally.
This update adds Unrecognized to the metric Unit Enum. In addition, the logic for converting to a Metric from raw data was updated to use this option if a ValueError occurs. This avoids the exception/breakage and allows the function to return appropriately.
Ideally the SDK would pull the list of metric types via API versus relying on a static Enum. With this solution, custom units will not be present (and will instead be Unrecognized). However, I'd rather have that result than have no ability to pull the data at all.
In the future, if someone chooses to implement a call to get all metric types, this approach can/should be replaced.
Thank you!