7 Commits (61b377db509bebdb67f00a2db8212cc69d95b47b)

Author	SHA1	Message	Date
Robert Fratto	642d826a00	chore(dataobj): make section tenancy a global construct (#18857) ... Signed-off-by: Robert Fratto <robertfratto@gmail.com> Co-authored-by: George Robinson <george.robinson@grafana.com>	9 months ago
Robert Fratto	100e259a8d	chore(dataobj): introduce the concept of section info "extensions" (#18832)	9 months ago
Robert Fratto	a237444f0d	refactor(dataobj): invert dependency between dataobj and sections (#17762) ... Originally, the dataobj package was a higher-level API around sections. This design caused it to become a bottleneck: * Implementing any new public behaviour for a section required bubbling it up to the dataobj API for it to be exposed, making it tedious to add new sections or update existing ones. * The `dataobj.Builder` pattern was focused on constructing dataobjs for storing log data, which will cause friction as we build objects around other use cases. This PR builds on top of the foundation laid out by #17704 and #17708, fully inverting the dependency between dataobj and sections: * The `dataobj` package has no knowledge of what sections exist, and can now be used for writing and reading generic sections. Section packages now create higher-level APIs around the abstractions provided by `dataobj`. * Section packages are now public, and callers interact directly with these packages for writing and reading section-specific data. * All logic for a section (encoding, decoding, buffering, reading) is now fully self-contained inside the section package. Previously, the implementation of each section was spread across three packages (`pkg/dataobj/internal/encoding`, `pkg/dataobj/internal/sections/SECTION`, `pkg/dataobj`). * Cutting a section is now a decision made by the caller rather than the section implementation. Previously, the logs section builder would create multiple sections. For the most part, this change is a no-op, with two exceptions: 1. Section cutting is now performed by the caller; however, this shouldn't result in any issues. 2. Removing the high-level `dataobj.Stream` and `dataobj.Record` types will temporarily reduce the allocation gains from #16988. I will address this after this PR is merged.	12 months ago
Robert Fratto	9be95a3e8c	chore(dataobj): reduce memory overhead of merging logs stripes (#16833)	1 year ago
benclive	7f32de6cf2	chore(dataobj): Refactor processor & builder to separate concerns (#16055)	1 year ago
benclive	ca4c025ad0	chore(dataobj): Create initial dataobj builder (#16011) ... Co-authored-by: Cyril Tovena <cyril.tovena@gmail.com> Co-authored-by: Robert Fratto <robertfratto@gmail.com>	1 year ago
Robert Fratto	1adb1e39d3	chore(dataobj): add initial high-level APIs for reading streams and log records (#15974)	1 year ago
Robert Fratto	948f5c5f3e	chore(dataobj): Reintroduce sorting of the logs section (#15906)	1 year ago
Robert Fratto	093e36af58	chore(dataobj): instrument data objects (#15803)	1 year ago
Robert Fratto	848c31fce9	chore(dataobj): temporarily disable sorting (#15799)	1 year ago
Robert Fratto	a35321c100	chore(dataobj): Prefix bucket and cache built object until flushing succeeds (#15796)	1 year ago
Robert Fratto	127ad5326f	chore(dataobj): support for building and flushing data objects (#15780)	1 year ago