Thanks for writing up this proposal, Wei. This will go a long way in
satisfying a number of Samza use-cases. I'm +1 to this idea.
>> Section on proposed changes: Provide hooks to transform an incoming
message to desired types (this is useful to store a subset of the incoming
message).
1. I
Thanks for writing up this proposal, Wei. This will go a long way in
satisfying a number of Samza use-cases. I'm +1 to this idea.
>> Section on proposed changes: Provide hooks to transform an incoming
message to desired types (this is useful to store a subset of the incoming
message).
1. I
Github user asfgit closed the pull request at:
https://github.com/apache/samza/pull/181
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Thanks for writing up this proposal, Wei. This will go a long way in
satisfying a number of Samza use-cases. I'm +1 to this idea.
>> Section on proposed changes: Provide hooks to transform an incoming
message to desired types (this is useful to store a subset of the incoming
message).
1. I
Hi, Wei,
+1 on the proposed design. This is going to reduce a lot of heavy-lifting
work that's needed done by user code today to bootstrap a data stream into
local store. The configs look quite straightforward and easy to set up.
Overall the design looks great to me.
I have one question: in the
Hi all,
This is an official CANCEL for the RC0 vote, and a status update for the
new RC. Resending this since previous emails did not get delivered to the
list.
We found a few issues in RC0 during further testing.
The following issues are already fixed and will be available in new RC:
Thanks Xinyu for your feedback. With regard to your question, when a new
version of a file becomes available, we would already be in the normal
processing mode, either the connector or external system would need to
inject an indication to signal the end of the current version and continue
send the
