[
https://issues.apache.org/jira/browse/CASSANDRA-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324622#comment-14324622
]
Benedict commented on CASSANDRA-8119:
-------------------------------------
It might be nice to permit either CL _or_ explicit integer requirement, so that
users can specify QUORUM without knowing the RF, or can specify a RF if they
care about a specific degree of durability. Generally +1 this improvement, and
don't have any qualms about special keys. We just need to make sure they are
unambiguously encoded distinctly from the datacentre names.
It might be nice to permit multiple occurences of the "any datacentre" special
key, so that you could specify QUORUM x2 DC, without specifying which DC either
occurs in. It might also be nice to have a special "local datacentre" key which
doesn't require the user (or client) to know its name.
> More Expressive Consistency Levels
> ----------------------------------
>
> Key: CASSANDRA-8119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8119
> Project: Cassandra
> Issue Type: New Feature
> Components: API
> Reporter: Tyler Hobbs
>
> For some multi-datacenter environments, the current set of consistency levels
> are too restrictive. For example, the following consistency requirements
> cannot be expressed:
> * LOCAL_QUORUM in two specific DCs
> * LOCAL_QUORUM in the local DC plus LOCAL_QUORUM in at least one other DC
> * LOCAL_QUORUM in the local DC plus N remote replicas in any DC
> I propose that we add a new consistency level: CUSTOM. In the v4 (or v5)
> protocol, this would be accompanied by an additional map argument. A map of
> {DC: CL} or a map of {DC: int} is sufficient to cover the first example. If
> we accept a special keys to represent "any datacenter", the second case can
> be handled. A similar technique could be used for "any other nodes".
> I'm not in love with the special keys, so if anybody has ideas for something
> more elegant, feel free to propose them. The main idea is that we want to be
> flexible enough to cover any reasonable consistency or durability
> requirements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
