Oh ok, I had assumed that distinguishing cases 1 and 2 was possible.
Thanks.
On 7 Jul 2016 1:02 p.m., "Guozhang Wang" wrote:
> Hello,
>
> The problem is that, in stream processing when you have a new record coming
> from the big table tB and does not find a match with the small table (i.e.
> onl
Hello,
The problem is that, in stream processing when you have a new record coming
from the big table tB and does not find a match with the small table (i.e.
only a sub set of keys in practice) in tA, you cannot tell which case of
the following is true:
1. there was a matching record in tA, which
thanks, I understand that it's not modelled the same way as database joins.
Let's take an example of inner join of very small population set (NBA
rookies or US senators) with larger table (data on zip codes). Let's assume
we want to identify the crime rate of zip codes where current senators live
Hello,
The KTable join semantics is not exactly the same with that of a RDBMS. You
can fine detailed semantics in the web docs (search for Joining Streams):
http://docs.confluent.io/3.0.0/streams/developer-guide.html#kafka-streams-dsl
In a nutshell, the joiner will be triggered only if both / le
Same happens for regular join, keys that appear only in one stream will
make it to output KTable tC with a null for either input stream. I guess
it's related to Kafka-3911 Enforce ktable Materialization or umbrella JIRA
3909, Queryable state for Kafka Streams?
On Mon, Jul 4, 2016 at 8:45 PM, Phili
If we have two streams A and B for which we associate tables tA and tB,
then create a table tC as ta.leftJoin(tB, ) and then we
have a key kB in stream B but never made it to tA nor tC, do we need to
inject a pair (k,v) of (kB, null) into resulting change log for tC ?
It sounds like it is definite