Not sure what CQL syntax for this is. Is it protocol level the way CL is?
That's a good question and I'm not really sure what's the right answer.
I think it may make the most sense to make it protocol level because of reads. For CAS writes, we do have a CQL syntax for it, so we could extends it with say:
UPDATE foo SET v1 = 2, v2 = 3 WHERE k = 1 IF v1 = 1 AND v2 = 1 IN LOCAL DC
But for reads, we don't have any syntax, the consistency level (SERIAL) is the only thing that makes a read go through paxos, so I'm afraid adding some CQL syntax in that case would be confusing.
But even making it protocol level is not that easy. For thrift, on the read side, the only way I can see us supporting this DC-local CAS would be add a LOCAL_SERIAL consistency level (short of duplicating all read methods for CAS reads that is). But that doesn't really work for writes since the consistency level for writes is really the consistency of the paxos learn/commit phase.
One option (the best I can come up with so far) would be to add the LOCAL_SERIAL consistency level, and then to change CAS write to take 2 CL: the first one would be for the commit (learn) phase (as we have now, but we would refuse CL.SERIAL and CL.LOCAL_SERIAL in that case) and a 2nd CL that would control the "Paxos consistency" (and for that one, only CL.SERIAL or CL.LOCAL_SERIAL would be valid). It's not perfect however because the one thing you can't properly express is the ability to do CL.SERIAL for paxos but don't wait on any node for the learn phase. Unless we make CL.ANY for the "commit consistency" mean that, but that's a slight stretch.
In any case, we should probably make it sure to shove that in 2.0.0 because I don't want to change the thrift API nor break the native protocol in 2.0.1.
Any better idea?