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

Jonathan Ellis commented on CASSANDRA-6870:
-------------------------------------------

Let's back up a bit.

We're trying to support
{{update table set col1=increment(col1), col2=trim(col2) where rowkey = 5}}
 or generalized to {{update table set col3=pow(col1, col2), col4=trim(col5) 
where rowkey = 5}}

I infer a couple things from this:
- 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.  I think this means we open up CL.SERIAL for normal 
UPDATE (without IF) when UDF are being invoked against data from an existing 
row.
- paxos always reads the existing values at QUORUM, but it looks like we will 
want to allow a separate CL to be specified for reads as well
- we need to be able to combine multiple function calls / transformations into 
a single update / paxos round.  I *think* this is straightforward but I may be 
wrong.
- sometimes a single output column is not enough.  how do we support more?  We 
could use {{(c1, c2) = f(c3, c4)}} syntax similar to what we introduced for 
composite partition keys.  Or we could add "out" parameters which is what most 
SQL UDF implementations do.  NB: I am fine with postponing implementation of 
this to another ticket, but I do think we should settle on the syntax ahead of 
time so that we don't accidentally make extending it harder than necessary.

> 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)

Reply via email to