fonsdant commented on code in PR #18314:
URL: https://github.com/apache/kafka/pull/18314#discussion_r1933744549
##########
docs/streams/developer-guide/dsl-api.html:
##########
@@ -3097,152 +3098,994 @@ <h5><a class="toc-backref" href="#id34">KTable-KTable
Foreign-Key
</div>
</div>
</div>
- <div class="section"
id="applying-processors-and-transformers-processor-api-integration">
- <span id="streams-developer-guide-dsl-process"></span><h3><a
class="toc-backref" href="#id24">Applying processors and transformers
(Processor API integration)</a><a class="headerlink"
href="#applying-processors-and-transformers-processor-api-integration"
title="Permalink to this headline"></a></h3>
- <p>Beyond the aforementioned <a class="reference internal"
href="#streams-developer-guide-dsl-transformations-stateless"><span class="std
std-ref">stateless</span></a> and
- <a class="reference internal"
href="#streams-developer-guide-dsl-transformations-stateless"><span class="std
std-ref">stateful</span></a> transformations, you may also
- leverage the <a class="reference internal"
href="processor-api.html#streams-developer-guide-processor-api"><span
class="std std-ref">Processor API</span></a> from the DSL.
- There are a number of scenarios where this may be
helpful:</p>
- <ul class="simple">
- <li><strong>Customization:</strong> You need to implement
special, customized logic that is not or not yet available in the DSL.</li>
- <li><strong>Combining ease-of-use with full flexibility
where it’s needed:</strong> Even though you generally prefer to use
- the expressiveness of the DSL, there are certain steps
in your processing that require more flexibility and
- tinkering than the DSL provides. For example, only
the Processor API provides access to a
- record’s metadata such as its topic, partition,
and offset information.
- However, you don’t want to switch completely to
the Processor API just because of that.</li>
- <li><strong>Migrating from other tools:</strong> You are
migrating from other stream processing technologies that provide an
- imperative API, and migrating some of your legacy code
to the Processor API was faster and/or easier than to
- migrate completely to the DSL right away.</li>
+ <div class="section"
id="applying-processors-processor-api-integration">
+ <a class="headerlink"
href="#applying-processors-processor-api-integration" title="Permalink to this
headline">
+ <h3>
+ <a class="toc-backref" href="#id24">Applying
processors (Processor API integration)</a>
+ </h3>
+ </a>
+ <p>Beyond the aforementioned <a class="reference internal"
+
href="#streams-developer-guide-dsl-transformations-stateless">
+ <span class="std std-ref">stateless</span></a> and
+ <a class="reference internal"
href="#streams-developer-guide-dsl-transformations-stateless"> <span
+ class="std std-ref">stateful</span></a>
transformations, you may also leverage the Processor API from the
+ DSL. There are a number of scenarios where this may be
helpful:
+ </p>
+ <ul>
+ <li><strong>Customization:</strong> You need to implement
special, customized logic that is not or not yet
+ available
+ in the DSL.</li>
+ <li><strong>Combining ease-of-use with full flexibility
where it's needed:</strong> Even though you generally
+ prefer
+ to use the expressiveness of the DSL, there are
certain steps in your processing that require more
+ flexibility and tinkering than the DSL provides. For
example, only the Processor API provides access to a
+ record's metadata such as its topic, partition, and
offset information. However, you don't want to switch
+ completely to the Processor API just because of that;
and</li>
+ <li><strong>Migrating from other tools:</strong> You are
migrating from other stream processing technologies
+ that
+ provide an imperative API, and migrating some of your
legacy code to the Processor API was faster and/or
+ easier than to migrate completely to the DSL right
away.</li>
</ul>
- <table border="1" class="non-scrolling-table width-100-percent
docutils">
- <colgroup>
- <col width="19%" />
- <col width="81%" />
- </colgroup>
- <thead valign="bottom">
- <tr class="row-odd"><th class="head">Transformation</th>
- <th class="head">Description</th>
- </tr>
+ <h4>Operations and concepts</h4>
+ <ul>
+ <li><code>KStream#process</code>: Process all records in a
stream, one record at a time, by applying a
+ <code>Processor</code> (provided by a given
<code>ProcessorSupplier</code>);
+ </li>
+ <li><code>KStream#processValues</code>: Process all
records in a stream, one record at a time, by applying a
+ <code>FixedKeyProcessor</code> (provided by a given
<code>FixedKeyProcessorSupplier</code>);
+ </li>
+ <li><code>Processor</code>: A processor of key-value pair
records;</li>
+ <li><code>ContextualProcessor</code>: An abstract
implementation of <code>Processor</code> that manages the
+ <code>ProcessorContext</code> instance and provides
default no-op implementation of
+ <code>Processor#close</code>.
Review Comment:
Updated.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
