Open djaglowski opened 7 months ago
cc @mx-psi @bogdandrutu
Personal preference:
func (es ResourceLogsSlice) ForEach(func(rl plog.ResourceLogs))
func (es ScopeLogsSlice) ForEach(func(sl plog.ScopeLogs))
func (es LogRecordSlice) ForEach(func(lr plog.LogRecord))
Add high-level ForEach in top level structs:
func (ms Logs) ForEachLogRecord(func(rl plog.ResourceLogs, sl plog.ScopeLogs, lr plog.LogRecord))
Wait for more feedback to come.
I think we can clearly do this in an additive way, so this is not required for pdata 1.0. I like @bogdandrutu's plan (but maybe we don't need all ForEach
s, I suspect for the most part components will benefit from ForEachLogRecord
and similar methods)
Is your feature request related to a problem? Please describe. Drilling through pdata structs in order to perform work on each items is very common but generally requires deeply nested and repetitive code.
Describe the solution you'd like We should consider adding
ForEach*
methods at various levels in the pdata hierarchy.The same code above could look something like:
This could be implemented at the level of each "Slice" struct. e.g.
Optionally, we could go one step further and expose these on the structs which contain Slices. e.g.
Describe alternatives you've considered As I understand it, the current pattern of requiring iteration using
Len
andAt
was intentional based on slight advantage in performance. I believe this level of optimization is helpful in some cases and should remain on the table as an option. However, I believe there is a tradeoff with component writability and maintainability which should be considered here as well.Additional context I'm not certain this would work as nicely for metric data points, since we have multiple types. Perhaps someone has ideas or opinions on this aspect in particular. e.g.