-
Notifications
You must be signed in to change notification settings - Fork 652
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
Add _ViewInstrumentMatch #2400
Add _ViewInstrumentMatch #2400
Conversation
It doesn't store views, it is the storage for a view. To me, Also curious what folks besides me and Diego think–here's the section of the design doc for this |
For what it's worth, I think other implementations are going with ViewsRegistry here (at least java/js are). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it's also not the storage for a view, as a single view may be associated with many of these objects (one per instrument) correct? In which case the relationship between ViewInstrument described in I don't know that |
opentelemetry-sdk/src/opentelemetry/sdk/_metrics/_view_instrument_match.py
Outdated
Show resolved
Hide resolved
Actually, the user does not do anything with a view and instrument match. They are an implementation detail, I have updated the class name and the PR title to reflect this. Implementation details should still have descriptive names. It is hard to describe what this class does, it has a A measurement that follows the
From point 1 to point 4 the measurement is handled sequentially by only one object. In step 5 the measurement is handled by several objects (instances of Because it is hard to describe what this class does or is, I believe it is better to stick to the facts, view and instruments can match and every time they match we get an instance of this class. It would be perfect if we could find a noun or adjective that describes it exactly, but I don't know one and I don't think either storage or registry describe them either. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ViewInstrumentJoin? ViewInstrumentUnion? I'm just throwing more ideas to see if any stick 😄
I'm ok with calling this a Match as well, tbh since this is an implementation detail I don't have a strong preference here.
Same here. |
I agree with @codeboten's point about "match"
but i'm fine to move on with the this name 👍 |
name: str, | ||
unit: str, | ||
description: str, | ||
aggregation: type, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does type
mean here?
class _ViewInstrumentMatch: | ||
def __init__( | ||
self, | ||
name: str, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just pass in the view here to get all of these properties? They are well defined there and then if more fields are added to the view, you don't need to update this constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These attributes don't necessarily come from the view, they may come from the instrument, like this.
if key in self._attribute_keys: | ||
attributes[key] = value | ||
else: | ||
attributes = measurement.attributes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this can be None
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, @codeboten fixed this in #2469. ✌️
|
||
attributes = frozenset(attributes.items()) | ||
|
||
if attributes not in self._attributes_aggregation.keys(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.keys()
is unnecessary here
Fixes #2300
This class is intentionally named
ViewInstrumentMatch
because it represents a match between a View and an Instrument. There will be as many instances ofViewInstrumentMatch
as there will be matches between Views and Instruments. I think this is a more descriptive name thanViewStorage
considering the fact that instances of this class do no store any Views.