You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

DRAFT

Current state: Under Discussion

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

JIRA: Unable to render Jira issues macro, execution error. Unable to render Jira issues macro, execution error.

Motivation

Kafka Streams enforces a strict non-null-key policy in the DSL across all key-dependent operations (like aggregations and joins).
For left-joins, it might make sense to still accept a `null`, and add the left-hand record with an empty right-hand-side to the result.
The defined semantics for left/outer join are: keep the stream record if no matching join record was found.
Thus, Kstreams todays behavior is incosistent with the defined semantics.

Public Interfaces

This KIP won't change any public interfaces. However, It will change the behavior of several stream dsl operators:

  • left KStream-table/globalTable
  • left/outer stream-stream
  • left-foreign-key table-table - allow foreign key to be null.

Proposed Changes

Make the above operators emit

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
  • If we are changing behavior how will we phase out the older behavior?
  • If we need special migration tools, describe them here.
  • When will we remove the existing behavior?

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

  • No labels