Yes, sounds good, Guozhang, thanks. I'll create a jira today.
-josh
On Thu, Apr 14, 2016, 1:37 PM Guozhang Wang wrote:
> Hi Josh,
>
> As we chatted offline, would you like to summarize your proposed Transform
> APIs in a separate JIRA so we can continue our discussions there?
>
> Guozhang
>
> O
Hi Josh,
As we chatted offline, would you like to summarize your proposed Transform
APIs in a separate JIRA so we can continue our discussions there?
Guozhang
On Tue, Apr 5, 2016 at 4:13 PM, Guozhang Wang wrote:
> HI Josh,
>
> Re 1): transform is only for usage in the higher-level DSL, while i
HI Josh,
Re 1): transform is only for usage in the higher-level DSL, while in the
lower-level APIs people are expected to work with Processor only, which for
now use context.forward() to send record to the downstream processors.
Re 2): I have a few questions for your propose: with different typed
Hi Guozhang,
I'll reply to your points in-line below:
On Tue, Apr 5, 2016 at 10:23 AM Guozhang Wang wrote:
> Hi Josh,
>
> I think there are a few issues that we want to resolve here, which could be
> orthogonal to each other.
>
> 1) one-to-many mapping in transform() function that generates a s
Hi Josh,
I think there are a few issues that we want to resolve here, which could be
orthogonal to each other.
1) one-to-many mapping in transform() function that generates a single
stream (i.e. single typed key-value pairs).
Since transform() already enforces to make type-safe return values, on
Hi all,
Just chiming in with Yuto: I think the custom Processor becomes attractive
in scenarios where a node in the graph may emit to a variety of downstream
paths, possibly after some delay, depending on logic. This can probably
often be achieved with the existing DSL using some combination of
pr
Thanks Yuto for your code snippet. Since you need to access a customized
external storage for metadata, that indeed cannot be wrapped in any
built-in operators in the Streams DSL yet, and your code example in the
previous email would be close to the best you can do with the high-level
DSL now.
One
2016-04-04 7:20 GMT+09:00 Guozhang Wang :
> Hi Yuto,
>
> Is the destination topic embedded as part of the value in the original
> "foo" topic? If yes could you just access that field directly instead of
> mapping to a (key, value, destination) triplet?
>
Nope. KeyValueWithDestination is just an ex
Hi Yuto,
Is the destination topic embedded as part of the value in the original
"foo" topic? If yes could you just access that field directly instead of
mapping to a (key, value, destination) triplet?
Guozhang
On Sun, Apr 3, 2016 at 9:29 AM, Yuto KAWAMURA
wrote:
> Hi Guozhang,
>
>
>
> 2016-04-
Hi Guozhang,
2016-04-02 3:29 GMT+09:00 Guozhang Wang :
> Hi Yuto,
>
> That is a good suggestion, the child index is not very intuitive from
> programmer's view and we can even consider replacing it with the processor
> name instead of overloading it. Could you file a JIRA?
>
Yep :) https://issu
Hi Yuto,
That is a good suggestion, the child index is not very intuitive from
programmer's view and we can even consider replacing it with the processor
name instead of overloading it. Could you file a JIRA?
Also I am wondering if you have looked at the higher-level Streams DSL, and
if yes could
11 matches
Mail list logo
