robertwb commented on a change in pull request #12426:
URL: https://github.com/apache/beam/pull/12426#discussion_r465400717
##########
File path: model/pipeline/src/main/proto/beam_runner_api.proto
##########
@@ -855,10 +855,21 @@ message StandardCoders {
// BOOLEAN: beam:coder:bool:v1
// BYTES: beam:coder:bytes:v1
// ArrayType: beam:coder:iterable:v1 (always has a known length)
- // MapType: not yet a standard coder (BEAM-7996)
+ // MapType: not a standard coder, specification defined below.
// RowType: beam:coder:row:v1
// LogicalType: Uses the coder for its representation.
//
+ // The MapType is encoded by:
+ // - An INT32 representing the size of the map (N)
+ // - Followed by N interleaved keys and values, encoded with their
+ // corresponding coder.
+ //
+ // Nullable types in container types (ArrayType, MapType) are encoded by:
+ // - A one byte null indicator, 0x00 for null values, or 0x01 for present
+ // values.
+ // - For present values the null indicator is followed by the value
+ // encoded with it's corresponding coder.
+ //
Review comment:
@lostluck The issue here is what kinds of objects the SDK must accept
when receiving these from a foreign SDK. If nulls are allowed, you cannot let
the element type be (say) a `map[str, int]` in go.
It looks like there is a way to specify in the schema whether the
keys/values could be null (or explicitly disallow it for either or both). The
encoding, on the other hand, always has this leading bit set (regardless of
whether the schema allows null values), but is harder to change for backwards
compatibility reasons. If this is the case, I'm OK with that.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
