Kafka.Record.Request

Documentation

data Record

Information about Record from Kafka documentation:

length: varint
attributes: int8
    bit 0~7: unused
timestampDelta: varlong
offsetDelta: varint
keyLength: varint
key: byte[]
valueLen: varint
value: byte[]
Headers => [Header]

Constructors

Record

Fields

• timestampDelta :: !Int64
• offsetDelta :: !Int32
• key :: !Bytes

  Setting the key to the empty byte sequence causes it to be treated as though it were the null key. Technically, we could do the right thing by wrapping the Bytes with Maybe, but using the empty string as the key is a terrible idea anyway.

• value :: !Bytes

  In a data-encoding setting, it actually makes more sense for this to be Chunks, not Bytes. But in a data-decoding setting, Bytes makes more sense. It might be better to create a separate type for each setting.

• headers :: !(SmallArray Header)

  In a data-encoding setting, it makes more sense for this to be a chunked (or builder-like) type.

data Header

Information about Header from Kafka documentation:

headerKeyLength: varint
headerKey: String
headerValueLength: varint
value: byte[]

Constructors

Header

Fields

• key :: !Text

  Header key. For records that we are encoding, text (rather than some kind of builder) is a reasonable choice since header keys are typically not assembled from smaller pieces.

• value :: !Bytes

  Header value. This is currently Bytes, and I'm torn about whether or not to change it to a builder or chunks type. On one hand, it makes a more sense for it to be done that way, but on the other hand, I do not think that values are particularly likely to be constructed since they are small.

toChunks :: Record -> Chunks

toChunksOnto :: Record -> Chunks -> Chunks

Variant of toChunks that gives the caller control over what chunks come after the encoded record. For example, it is possible to improve the performance of

foldMap toChunks records

by rewriting it as

foldr toChunksOnto ChunksNil records