[ 
https://issues.apache.org/jira/browse/FLINK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Flink Jira Bot closed FLINK-6936.
---------------------------------
    Resolution: Auto Closed

This issue was labeled "stale-minor" 7 ago and has not received any updates so 
I have gone ahead and closed it.  If you are still affected by this or would 
like to raise the priority of this ticket please re-open, removing the label 
"auto-closed" and raise the ticket priority accordingly.


> Add multiple targets support for custom partitioner
> ---------------------------------------------------
>
>                 Key: FLINK-6936
>                 URL: https://issues.apache.org/jira/browse/FLINK-6936
>             Project: Flink
>          Issue Type: Improvement
>          Components: API / DataStream
>            Reporter: Xingcan Cui
>            Assignee: Xingcan Cui
>            Priority: Minor
>              Labels: auto-closed, stale-assigned
>
> The current user-facing Partitioner only allows returning one target.
> {code:java}
> @Public
> public interface Partitioner<K> extends java.io.Serializable, Function {
>       /**
>        * Computes the partition for the given key.
>        *
>        * @param key The key.
>        * @param numPartitions The number of partitions to partition into.
>        * @return The partition index.
>        */
>       int partition(K key, int numPartitions);
> }
> {code}
> Actually, this function should return multiple partitions and this may be a 
> historical legacy.
> There could be at least three approaches to solve this.
> # Make the `protected DataStream<T> setConnectionType(StreamPartitioner<T> 
> partitioner)` method in DataStream public and that allows users to directly 
> define StreamPartitioner.
> # Change the `partition` method in the Partitioner interface to return an int 
> array instead of a single int value.
> # Add a new `multicast` method to DataStream and provide a MultiPartitioner 
> interface which returns an int array.
> Considering the consistency of API, the 3rd approach seems to be an 
> acceptable choice. [~aljoscha], what do you think?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to