This is an automated email from the ASF dual-hosted git repository. mjsax pushed a commit to branch 2.8 in repository https://gitbox.apache.org/repos/asf/kafka.git
commit 893bd88f170f26df47ba8a03bcc976903229b0bd Author: Jim Galasyn <[email protected]> AuthorDate: Fri Apr 9 11:41:52 2021 -0700 MINOR: Fix left/outer join descriptions in Streams DSL reference topic (#10453) Reviewer: Matthias J. Sax <[email protected]> --- docs/streams/developer-guide/dsl-api.html | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/docs/streams/developer-guide/dsl-api.html b/docs/streams/developer-guide/dsl-api.html index 3c885d6..84fe4e7ff 100644 --- a/docs/streams/developer-guide/dsl-api.html +++ b/docs/streams/developer-guide/dsl-api.html @@ -2232,8 +2232,8 @@ Map<String, KStream<String, Long>> branches = <blockquote> <div><ul class="simple"> <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> key are ignored and do not trigger the join.</li> - <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table. Tombstones do not - trigger the join. When an input tombstone is received, then an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding + <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table. Right-tombstones trigger the join, + but left-tombstones don't: when an input tombstone is received, an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding key actually exists already in the join result KTable).</li> </ul> </div></blockquote> @@ -2280,8 +2280,8 @@ Map<String, KStream<String, Long>> branches = <blockquote> <div><ul class="simple"> <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> key are ignored and do not trigger the join.</li> - <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table. Tombstones do not - trigger the join. When an input tombstone is received, then an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding + <li>Input records with a <code class="docutils literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the deletion of the key from the table. Tombstones may trigger joins, + depending on the content in the left and right tables. When an input tombstone is received, an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding key actually exists already in the join result KTable).</li> </ul> </div></blockquote> @@ -2515,7 +2515,8 @@ Map<String, KStream<String, Long>> branches = literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the - deletion of the key from the table. When an input + deletion of the key from the table. Tombstones do not + trigger the join. When an input tombstone is received, then an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the @@ -2574,8 +2575,9 @@ Map<String, KStream<String, Long>> branches = literal"><span class="pre">null</span></code> value are interpreted as <em>tombstones</em> for the corresponding key, which indicate the - deletion of the key from the table. When an input - tombstone is received, then an output + deletion of the key from the table. Right-tombstones + trigger the join, but left-tombstones don't: + when an input tombstone is received, then an output tombstone is forwarded directly to the join result KTable if required (i.e. only if the corresponding key actually exists already in
