-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
[pkg/ottl] adapt mapGetter
to handle nested map items within slices
#37408
[pkg/ottl] adapt mapGetter
to handle nested map items within slices
#37408
Conversation
… pcommon types Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Converting back to draft for now, due to #37280 (comment) |
…er instead Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
mapGetter
to return raw mapsmapGetter
to handle nested map items within slices
@@ -480,6 +481,19 @@ func (p *Parser[K]) ParseValueExpression(raw string) (*ValueExpression[K], error | |||
} | |||
|
|||
return &ValueExpression[K]{ | |||
getter: getter, | |||
getter: &StandardGetSetter[K]{ |
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.
If we end up stick to this approach, considering the mapGetter
is now returning pcommon.Map
values, I think we could keep it consistent and remove these changes, so all maps would still be parsed aspcommon.Map
instead of raw values. I guess it would be a breaking change, though. WDYT?
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'd be fine with that, however there are also arguments for returning the raw types here (#37280 (comment)). I think I would also prefer to consistently return pcommon.Map
values though. @evan-bradley @TylerHelmuth WDYT?
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.
Judging by #37280 (comment), we probably need to survey this a bit more to make sure we're either consistent everywhere, or can translate at any given point in the chain. I'm not sure I have a strong opinion here, but it sounds like at a minimum we could potentially use more tests.
Do the same issues apply to slices with []any
vs. pcommon.Slice
?
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.
for slices, this issue doesn't apply, as the listGetter
returns []any
as opposed to pcommon.Slice
:
opentelemetry-collector-contrib/pkg/ottl/expression.go
Lines 164 to 176 in ee2d165
func (l *listGetter[K]) Get(ctx context.Context, tCtx K) (any, error) { | |
evaluated := make([]any, len(l.slice)) | |
for i, v := range l.slice { | |
val, err := v.Get(ctx, tCtx) | |
if err != nil { | |
return nil, err | |
} | |
evaluated[i] = val | |
} | |
return evaluated, nil | |
} |
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 agree with @edmocosta that we should continue returning pcommon.Map
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.
Alright, I now changed it again to return pcommon.Map
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
This looks about ready to merge. I think it'd be great to make sure @evan-bradley can review one more time. |
Before merging it, I think we still need to address this #37408 (comment), if @evan-bradley agrees, we would need to undo those changes to keep returning pcommon.Map. |
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
Signed-off-by: Florian Bacher <florian.bacher@dynatrace.com>
@evan-bradley please review and merge if ok? |
Description
This PR fixes the limitations described in #37405. The recently introduced
ValueExpression
had to be adapted, and will now only return raw types, instead of theirpcommon.Map
/pcommon.Slice
eqivalents, as suggested in #37280 (comment)Link to tracking issue
Fixes #37405
Testing
Adapted and extended the unit and e2e tests