Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Status

Current state: Under Discussion Adopted

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread] 

JIRA: KAFKA-8455 

Motivation

Often, when reading an input topic, the key is expected to be null, but there's actually no way to represent this fact in Consumed, leading to confusing type signatures down the topology. For example, you might use the BytesSerde, but then you have a KStream<Bytes,...>. When maintaining a large application, this becomes a hazard, since you'd need to "be really careful" not to try and dereference the key at any point, since you actually know it's always null. One might use the BytesSerde, but then you have a KStream<Bytes,...>. When maintaining a large application, this becomes a hazard, since you'd need to "be really careful" not to try and dereference the key at any point, since you actually know it's always null.

Public Interfaces

I propose to add the following new SerDe:

...

Code Block
languagejava
titleNothingSerde
static public final class NothingSerdeVoidSerde extends WrapperSerde<Void> {
    public NothingSerde() {
        super(new NothingSerializer(), new NothingDeserializer());
    }
}

public class NothingSerializerVoidSerializer implements Serializer<Void> {
    @Override public byte[] serialize(String topic, Void data) {
        return new byte[0];
    }
}

public class NothingDeserializerVoidDeserializer implements Deserializer<Void> {
    @Override public Void deserialize(String topic, byte[] data) {
        return null;
    }
}}

If not null parameters passed then an java.lang.IllegalArgumentException will be thrown.

Proposed Changes

I want to add NothingSerde to main SerDe collection VoidSerde to Serdes class.

Compatibility, Deprecation, and Migration Plan

There is are no compatibility issues here.

Rejected Alternatives

One might use the BytesSerde, but then you have a KStream<Bytes,...>. When maintaining a large application, this becomes a hazard, since you'd need to "be really careful" not to try and dereference the key at any point, since you actually know it's always nullNullSerdesNothingSerdes naming was rejected during KIP discussion.