[
https://issues.apache.org/jira/browse/CASSANDRA-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13941935#comment-13941935
]
Sylvain Lebresne commented on CASSANDRA-6870:
---------------------------------------------
bq. this should support normal CL conventions. So if I want to trim without
paxos because I'm confident that there are no races, I shouldn't have to pay
that extra latency cost.
So we're talking about introducing read-before-write behavior even without
Paxos? I don't know how excited I am about that, it's been kind of the number 1
"don't do" for C* for a long time. Maybe it deserves a separate conversation at
least?
In term of implementation, I'll note that it would nice to build on top of the
existing function code (I'm thinking of the cql3.functions package here). We
definitively need some generalization, but a lot of things already exists, so
we shouldn't reinvent the wheel.
On a more general level, I do have to note that stuff like 'increment' will not
really work all that well, because even paxos can timeout (and in fact the
current implementation can timeout quite easily if there is contention, even in
case where we haven't truly timed out) and users should be able to handle that.
If you use conditional updates to ensure you're not creating twice the same
user profile for instance, it's relatively easy, but if you channel some
function through paxos, it's quickly harder (and it's impossible in the case of
increment as far as I can tell). Tbh, I can't see too many simple use cases
from the top of my head where you'd do something interesting with a
function-through-paxos and still be able to properly handle timeouts so maybe
it's worth finding a few non-toy example of that first? Not that I'm opposed to
the idea in principle.
> Transform operation
> -------------------
>
> Key: CASSANDRA-6870
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6870
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Edward Capriolo
> Assignee: Edward Capriolo
> Priority: Minor
>
> Compare and swap uses paxos to only update a value only if some criteria is
> met. If I understand correctly we should be able to use this feature to
> provide a wider variety of server side operations.
> For example inside a paxos transaction performing a slice and then using a
> function to manipulate the slice. You could accomplish features like append
> and increment this way without user needing to know the current value.
> I took a stab at doing this. I **think** I did it correctly. Comments welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
