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 Fri, 21 Mar 2014 15:51:45 GMT


Edward Capriolo commented on CASSANDRA-6870:

1) you don't want to use the paxos path unless you really care about it's serializability
guarantees because it's really very inefficient if you don't (more than doing a read-before-write
client side)
I could see two forms of this feature transform() and atomic_transform(). Atomic transform
would run the paxos path the other would not. transform() as optimistic atomic_transform()
as the safe version.

Anyway, what I'm saying is, I'm not opposed to channeling function calls through Paxos in
principle and it's definitively technically possible, but as with every feature, we should
avoid to do it just because we can as this leads to feature creep, so I think it would be
beneficial to first come up with a few concrete example of when it could be used that, example
that make it clear what we win by adding this. Incrementation is imo not one such example
because you can't handle timeouts and thus can't have exact counters.{quote} I have a use case where I need to support a large number of commands
in the redis api. Many of these functions can be converted into wide row problems, like append.
However the blind write/wide row scenario gives us unpredictable space usage. I would rather
my append change a single column, I can build rules inside the append to prune the column
as well. The majority of the redis commands likely read-before-write. The rationality of this
transform feature is to create one meta-operation that is pluggable and general purpose. 

A concrete example is I have two collections inside a
cql row, named unstarted and finished. I wish to take an item off unstarted -> add it to
finished and return it. This functional transform can generalize many things like this. Much
easier then me attempting to suggest 1 feature per redis command :)

> 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