• Key access to ValueTransformer:  While transforming values via KStream.transformValues and ValueTransformer, the key associated with the value may be needed, even if it is not changed. For instance, it may be used to access stores.

  As of now, the key is not available within these methods and interfaces, leading to the use of KStream.transform and Transformer, and the unnecessary creation of new KeyValue objects.

• Key access to ValueMapper: ValueMapper should have read-only access to the key for the value it is mapping. Sometimes the value transformation will depend on the key.

  It is possible to do this with a full blown KeyValueMapper but that loses the promise that you won't change the key – so you might introduce a re-keying phase that is totally unnecessary.

• Key access to ValueJoiner interface: In working with Kafka Stream joining, it's sometimes the case that a join key is not actually present in the values of the joins themselves (if, for example, a previous transform generated an ephemeral join key.) In such cases, the actual key of the join is not available in the ValueJoiner implementation to be used to construct the final joined value. This can be worked around by explicitly threading the join key into the value if needed, but it seems like extending the interface to pass the join key along as well would be helpful

Public Changes

There are no public changes to ensure the backwards-compatibility. 

Proposed Changes

The following methods will be added to KStream interface

<VR> KStream<K, VR> flatMapValues(final ValueMapperWithKey<? super V, ? extends Iterable<? extends VR>> processor);

<VO, VR> KStream<K, VR> join(final KStream<K, VO> otherStream,

 final ValueJoinerWithKey<? super V, ? super VO, ? extends VR> joiner,
   final JoinWindows windows,

 final Serde<K> keySerde,
 final Serde<V> thisValueSerde,
 final Serde<VO> otherValueSerde);

<VO, VR> KStream<K, VR> leftJoin(final KStream<K, VO> otherStream,
 final ValueJoinerWithKey<? super V, ? super VO, ? extends VR> joiner,
 final JoinWindows windows,
 final Serde<K> keySerde,
 final Serde<V> thisValSerde,
 final Serde<VO> otherValueSerde);

<VO, VR> KStream<K, VR> outerJoin(final KStream<K, VO> otherStream,
 final ValueJoinerWithKey<? super V, ? super VO, ? extends VR> joiner,
 final JoinWindows windows,
 final Serde<K> keySerde,
 final Serde<V> thisValueSerde,
 final Serde<VO> otherValueSerde);

Proposed Changes

The PR can be found here.

Test Plan

The unit tests are changed accordingly to support the changes in core classes.

Rejected Alternatives

• Lambdas are not supported

  
  

public interface RichFunction {
    void init(final ProcessorContext context);

 void close();
}

public abstract class AbstractRichFunction implements RichFunction {
    @Override
  public void init(final ProcessorContext context) {}

    @Override
  public void close() {}
}

public abstract class RichValueJoiner<K, V1, V2, VR> extends AbstractRichFunction implements ValueJoiner<V1, V2, VR>  {
    @Override
  public final VR apply(final V1 value1, final V2 value2) {
        return apply(null, value1, value2);
  }

    public abstract VR apply(final K key, final V1 value1, final V2 value2);
}

KStreamFlatMapValues(ValueMapper<? super V, ? extends Iterable<? extends V1>> mapper) {
    this.mapper = mapper;
  isRichFunction = mapper instanceof RichValueMapper ? true : false;
}

@Override
public void process(K key, V value) {
    Iterable<? extends V1> newValues;
 if (isRichFunction) {
        newValues = ((RichValueMapper<? super K, ? super V, ? extends Iterable<? extends V1>>) mapper).apply(key, value);
  } else {
        newValues = mapper.apply(value);
  }
    for (V1 v : newValues) {
        context().forward(key, v);
  }
}

The PR can be found here.

Test Plan

Rejected Alternatives

• Not backward-compatible

We propose adding key information for ValueJoiner,  ValueTransformer, and ValueMapper classes and their apply(...) methods.

As a result, we perform the following public changes (and their overloaded versions)

•       Lacking performance because deep-copy and need for RichFunctions

1. We extend the target interfaces ValueJoiner,  ValueTransformer, and ValueMapper as ValueJoinerWithKey,  ValueTransformerWithKey, and ValueMapperWithKey. In extended abstract classes we have an access to keys.
2. In Processor we check the actual instance of object:
    

   this.valueTransformer = valueTransformer;
   if (valueTransformer instanceof ValueTransformerWithKey) {
   isTransformerWithKey = true;
   } else {
   isTransformerWithKey = false;
   }

   ..............

   ..............

   @Override
   public void process(K key, V value) {
   if (isTransformerWithKey) {
   K keyCopy = (K) Utils.deepCopy(key);
     context.forward(key, ((ValueTransformerWithKey<K, V, R>) valueTransformer).transform(keyCopy, value));
     } else {
   context.forward(key, valueTransformer.transform(value));
     }
   }

   

3. As we can see from the above code snippet, we can guard the key change in Processors by deeply copying the object before calling the apply() method.