[ https://issues.apache.org/jira/browse/CASSANDRA-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025976#comment-13025976 ]
Jonathan Ellis commented on CASSANDRA-2369: ------------------------------------------- The more I think about this the more I suspect that what I'm asking for here is a return to the assumption that keys:tokens are 1:1, i.e., incompatible with CASSANDRA-1034. It's actually even worse than that, because nodes own token _ranges_: if I have tokens X Y and Z that sort in that order, and a node has range (T, Z] then they all have to be on that node, no matter what the original keys were. So I think the right approach is not to mess with ReplicationStrategy api, but rather to build some kind of row-aware partitioner that generates tokens with extra metadata, e.g., a (hash, {dc1: 2, dc2: 0, dc3: 1}) tuple. Then the strategy would only have to run logic similar to NTS, except instead of per-keyspace strategy options it would get them from the Token object. > support replication decisions per-key > ------------------------------------- > > Key: CASSANDRA-2369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2369 > Project: Cassandra > Issue Type: New Feature > Reporter: Jonathan Ellis > Assignee: paul cannon > Priority: Minor > Fix For: 1.0 > > > Currently the replicationstrategy gets a token and a keyspace with which to > decide how to place replicas. for per-row replication this is insufficient > because tokenization is lossy (CASSANDRA-1034). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira