[
https://issues.apache.org/jira/browse/FLINK-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210480#comment-15210480
]
ASF GitHub Bot commented on FLINK-3659:
---------------------------------------
Github user gyfora commented on the pull request:
https://github.com/apache/flink/pull/1831#issuecomment-200907475
@StephanEwen
This PR does not change the behaviour of any existing Flink applications.
It now allows though that users only specify key of one input of the
comapfunctions for instance:
`input1.keyBy(...).connect(input2.broadcast())`
This was previously impossible which probably blocks many existing
use-cases (actually blocking one of my own applications that I try to build on
Flink) where one input does not have associated state.
After this change the key-value state defined by the keyed input stream
works as expected.
The only not so fortunate behaviour is that users can still call
state.value() for inputs from the non-keyed stream and the behaviour is not
clearly defined. If there was already input from the other side it returns the
state for the last key, otherwise it will probably throw a nullpointer
exception.
I think this is acceptable behaviour for the time being because well
written programs will work as expected. We can think about how we want to
handle the other non-keyed input but that will probably include changing many
things in the KvBackends so they can do this properly. This problem already
exists in flink as state access outside of the processing method is not well
defined.
> Allow ConnectedStreams to Be Keyed on Only One Side
> ---------------------------------------------------
>
> Key: FLINK-3659
> URL: https://issues.apache.org/jira/browse/FLINK-3659
> Project: Flink
> Issue Type: Improvement
> Components: Streaming
> Affects Versions: 1.0.0
> Reporter: Aljoscha Krettek
> Assignee: Aljoscha Krettek
>
> Currently, we only allow partitioned state when both inputs are keyed (with
> the same key type). I think a valid use case is to have only one side keyed
> and have the other side broadcast to publish some updates that are relevant
> for all keys.
> When relaxing the requirement to have only one side keyed we must still
> ensure that the same key is used if both sides are keyed.
> [~gyfora] Did you try this with what you're working on?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
