| commit | 0171119de155de48e83fea120d8a63ef4176a8fc | [log] [tgz] |
|---|---|---|
| author | Marcin Kowalczyk <qrczak@google.com> | Fri Nov 14 19:20:53 2025 +0100 |
| committer | qrczak <qrczak@google.com> | Fri Nov 14 19:31:54 2025 +0100 |
| tree | 60311dd8729a544d50d5efbf0eaea10ee0b7e680 | |
| parent | 349689ba7c8a3cedc4ce8bea9b790dbb82ea2ead [diff] |
Bring `SerializedMessageReader2` with a `Reader` source and a string source
closer together, so that `SerializedMessageReader2::Read()` does not distinguish
between field handlers applicable to a `Reader` source, and applicable to a
string source:
* In the field handler protocol, a field handler for length-delimited fields
is always applicable to a `Reader` source, and possibly also applicable
to a string source. If the underlying implementation only reads from
`absl::string_view`, reading from `ReaderSpan<>` is implemented by reading
to `absl::string_view` first.
* For calling `SerializedMessageReader2::Read()` with a string while some field
handlers are not applicable to a string source, the source is wrapped in
`StringReader`, and field handlers are called with the `Reader` source.
It is important for this adaptation to happen on the level of
`SerializedMessageReader2::Read()` rather than for each field handler,
so that a single `StringReader` is set up once.
* In `SerializedMessage{,Backward}Writer`, make `CopyString()` applicable also
to `absl::string_view`, in which case it is equivalent to `WriteString()`.
This is useful for generic handlers of length-delimited fields for
`SerializedMessageReader2`.
Also, in the field handler protocol, separate
`HandleLengthDelimitedFromReader()` from `HandleLengthDelimitedFromString()`
instead of relying on overloading. On this lower level they are always
implemented separately, and this makes it explicit which of them are defined.
PiperOrigin-RevId: 832366939
Riegeli/records is a file format for storing a sequence of string records, typically serialized protocol buffers. It supports dense compression, fast decoding, seeking, detection and optional skipping of data corruption, filtering of proto message fields for even faster decoding, and parallel encoding.
See documentation.
Riegeli file format will only change in a backward compatible way (i.e. future readers will understand current files, but current readers might not understand files using future features).
Riegeli C++ API might change in incompatible ways.