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

Tyler Hobbs commented on CASSANDRA-8119:
----------------------------------------

bq. this is a niche requirement

I disagree. Good multi-datacenter support is one of Cassandra's most popular 
features.  Having the ability to control consistency levels per-DC can be very 
useful.

bq. Additionally, you can't really encapsulate it in a UDF, as there are more 
factors that are CL-dependent. The behaviour of read repair, and speculative 
retry, can/should wary a lot depending on a CL

I don't think the CL should be _only_ a UDF.  Other options could be specified 
through {{WITH}} clauses.  For example, something like {{WITH READ REPAIR = 
'dclocal'}}.  I'm just making that up, but we do have a lot of flexibility here.

bq. Also, while you could stick it to schema, I don't see how it's a fit, 
conceptually, and not a (conceptually) dirty hack.

I'm not sure what you mean.  Care to elaborate?

> More Expressive Consistency Levels
> ----------------------------------
>
>                 Key: CASSANDRA-8119
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8119
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>            Reporter: Tyler Hobbs
>             Fix For: 3.x
>
>
> 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)

Reply via email to