-
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
[pkg/ottl] adapt mapGetter
to handle nested map items within slices
#37408
base: main
Are you sure you want to change the base?
Conversation
… pcommon types Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Converting back to draft for now, due to #37280 (comment) |
…er instead Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
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?
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