cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6870) Transform operation
Date Thu, 20 Mar 2014 16:24:43 GMT


Edward Capriolo commented on CASSANDRA-6870:

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.
I was wondering if it made sense to support transform and transform_atomic for this case.
IE the default transform does not have to happen in paxos at all. 

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.

In hive UDF returns a single value. This is a pure definition of function. There is a different
interface UDTF that returns multiple columns or even rows. It looks like this:
select parsurl(url, 'host', 'port') as a,b

I would suggest to differentiate a UDF which works like a mathamatical function,from a UDTF.
Trying to make them one uber-interface would probably make said interface hard to implement.

> Transform operation
> -------------------
>                 Key: CASSANDRA-6870
>                 URL:
>             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

View raw message