ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignite TC Bot (Jira)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-10223) Affinity methods should return List instead of Collection
Date Wed, 04 Sep 2019 08:13:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922270#comment-16922270
] 

Ignite TC Bot commented on IGNITE-10223:
----------------------------------------

{panel:title=Branch: [pull/6837/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--&gt; Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=4564401&amp;buildTypeId=IgniteTests24Java8_RunAll]

> Affinity methods should return List instead of Collection
> ---------------------------------------------------------
>
>                 Key: IGNITE-10223
>                 URL: https://issues.apache.org/jira/browse/IGNITE-10223
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Stanislav Lukyanov
>            Assignee: Diana Iakovleva
>            Priority: Minor
>              Labels: newbie
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Methods of class Affinity should return List instead of Collection when order of nodes
matters.
> The following methods are supposed to always return a collection with primary node preceding
backups:
> Affinity::mapPartitionToPrimaryAndBackups
> Affinity::mapKeyToPrimaryAndBackups
> The return type for both methods is Collection<ClusterNode>. The Javadocs say:
"Note that primary node is always first in the returned collection".
> In general, the notion of "order" and "first element" is not defined for a Collection
(we could play with iterators, but its awkward from both code and logic perspective). It makes
more sense for this methods to return List instead.
> The task is to introduce List equivalents of these methods. It would also be nice to
check if other APIs have similar issues.
> The tricky part is compatibility.
> Changing return type from Collection to List is source compatible (meaning the old client
code will compile with the new method), but not binary compatible (meaning the already compiled
client code will break because the signature has changed).
> A compatible solution would be to
> - deprecate the existing methods
> - add methods with different names, like mapPartitionToPrimaryAndBackups*List*



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Mime
View raw message