[
https://issues.apache.org/jira/browse/CASSANDRA-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943175#comment-13943175
]
Edward Capriolo commented on CASSANDRA-6870:
--------------------------------------------
{quote}
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)
{quote}
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.
{quote}
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}
http://redis.io/commands. 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 http://redis.io/commands/brpoplpush. 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: 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)
