-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[schema processor] Part 3 - Modifiers and Revisions #12147
[schema processor] Part 3 - Modifiers and Revisions #12147
Conversation
0b1ccac
to
7c3825a
Compare
Please rebase. |
As the schema processor improves, this package path changes to help make sense of what is trying to do.
As the schema processor improves, this package path changes to help make sense of what is trying to do.
A modifier allows mutating a signal from a previous version to the current one and vice versa.
A revision handles applying the modifiers to incoming signals and converting a signal to the next version.
2d0f70b
to
0674cf7
Compare
@tigrannajaryan would it also make sense to remove the change log for this PR as well? Edit: There was no external facing change here that impact users, removing the changelog. |
// Interesting thing of note, | ||
// ordering of these methods is important | ||
// otherwise you will get repeated values |
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.
The comment is a bit imprecise. What really matters that v
returned by Get
is a reference. If you call Remove
it results in v
reference to become invalid (it will likely point to some other attribute, but it can also point past the slice, so be totally undefined). So, this requires that v
must be used before Remove
is called.
Perhaps remove the "otherwise you will get repeated values" part, since it can be worse than that.
|
||
// modify is one change that can be made to a signal | ||
type modify struct { | ||
names map[string]string |
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.
It may be useful to use type aliases from "go.opentelemetry.io/otel/schema" instead of string
, so that it is clear what string this is, (e.g. AttributeName
).
names map[string]string | ||
|
||
appliesTo map[string]struct{} | ||
attrs map[string]string |
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.
It may be useful to use type aliases from "go.opentelemetry.io/otel/schema" instead of string
, so that it is clear what string this is, (e.g. AttributeName
).
Same for other string
s in this struct.
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.
I believe the reason why I didn't do that is that go defines them as new types instead of aliases so some operations had extra cruft that I cut out by keeping it as just strings.
type modify struct { | ||
names map[string]string | ||
|
||
appliesTo map[string]struct{} |
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.
Add comment to explain that if this is empty then the modification applies to everything (as opposed to nothing).
s.Attributes().Sort() | ||
s.SetName("foo") | ||
|
||
fixture.ParallelRaceCompute(t, 100, func() error { |
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 this test verify? Since we are using Clone
then the test can't fail. Are we verifying that Clone
works correctly?
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.
At this point I was validating that concurrent access to the modifiers would not cause race condition.
This is more a safety check more than anything else.
|
||
// Modifier abstracts a verion change that allows | ||
// for the changes to be updated or revert. | ||
type Modifier interface { |
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 interface is probably fine for now, but it likely need to change because we have recently introduced more complicated changes. The Schema File Format 1.1 brought the "split" transformation which changes both the metric name and the attribute name at the same time: https://github.com/open-telemetry/opentelemetry-go/blob/1eae91b3b099af62100cd630cd1cab89fe841615/schema/v1.1/ast/metrics.go#L40
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.
Yeah, so thinking about this I believe the Modifier may also need to be versioned in code to ensure behaviour.
Sorry, I do intend to get back to this however, I am busy with some internal work atm. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
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.
Just trying to revive an old PR, sorry for the absence. A lot has happened for me these months.
s.Attributes().Sort() | ||
s.SetName("foo") | ||
|
||
fixture.ParallelRaceCompute(t, 100, func() error { |
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.
At this point I was validating that concurrent access to the modifiers would not cause race condition.
This is more a safety check more than anything else.
names map[string]string | ||
|
||
appliesTo map[string]struct{} | ||
attrs map[string]string |
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.
I believe the reason why I didn't do that is that go defines them as new types instead of aliases so some operations had extra cruft that I cut out by keeping it as just strings.
|
||
// Modifier abstracts a verion change that allows | ||
// for the changes to be updated or revert. | ||
type Modifier interface { |
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.
Yeah, so thinking about this I believe the Modifier may also need to be versioned in code to ensure behaviour.
@MovieStoreGuy Welcome back! Looks like I cannot reopen the PR. You may need to create a new PR and link to this one. |
* [schema processor] Modifier A modifier allows mutating a signal from a previous version to the current one and vice versa. [schema processor] Adding revisions A revision handles applying the modifiers to incoming signals and converting a signal to the next version. * Adding changes * Adding migrate package. Following patterns similar to databases where you'd apply changes and rollback. the Migrate packages follows these designs to help make it clear what it is trying to do. * Removing modiferies to avoid confusion * Fixing up naming issues * Adding checks in for building a revision * Fixing up replaces * Removing transform files * Fixing naming * Fixing up conflict * Fixing typo * Updating naming * Fixing up ast usage * FIxing up generated mod files * Fixing up license headers
@MovieStoreGuy do you plan to reopen Part 4? |
Description:
An extension of #12146
This PR adds in support for Modifier an incoming signal type and a Revision which applies the modifiers