Hi Matthias,
Thanks for the good questions.
There is still the option of not using cached state. If one uses cached state
it will dedup for stores and forwarding further. But you can always disable
caching and do what you say.
Eno
> On 4 Sep 2016, at 17:36, Matthias J. Sax <matth...@confluent.io> wrote:
>
> Sorry for not being precise. What I meant be "completely" is for a
> single processor. Assume I want to have the following pattern:
>
> process(...) {
> if (someCondition) {
> state.put(...)
> context.forward(...);
> } else {
> context.forward(...);
> }
>
> Ie, for some record I do update the state and emit output records, for
> other records I only emit output records. This work in current design.
> However, if a "cached state" would be used, it would not work any more.
>
>
> -Matthias
>
> On 09/04/2016 05:58 PM, Damian Guy wrote:
>> Hi Matthias,
>>
>> Thanks for bringing the conversation across to the thread.
>>
>> I think a main limitation would be, that you cannot mix the 4 patterns
>>> within a single application anymore (iff you use a "caches state"). If
>>> you have processor with a "cached state" this disables direct usage of
>>> context.forward() completely -- if I understand the design correctly.
>>> Thus, if a "cached state" is used, forwarding is only possible via state
>>> updates.
>>>
>>>
>> The above statement is not correct. Caching doesn't completely disable
>> forwarding, it only disables it for Processors that are using State Stores.
>> In all other cases context.forward() works as it does now.
>>
>> Thanks,
>> Damian
>>
>
