[
https://issues.apache.org/jira/browse/CASSANDRA-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870906#action_12870906
]
Jan Kantert commented on CASSANDRA-1016:
----------------------------------------
Hi Jeff,
why did you implement this in db.Table? Why didnt you implement this in the
service.StorageProxy?
Correct me if i'm wrong: With replication factor N=3 and quorum write the
"coprocessor" will get executed 2 times on every write (once on every node).
Where is the advantage in this solution?
In my index implementation I hook into service.StorageProxy mutate and
mutateBlocking for writes. Are there any disadvantages to add it here?
Regards,
Jan
> Coprocessors
> ------------
>
> Key: CASSANDRA-1016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1016
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Ryan King
> Attachments: CASSANDRA-1016.patch
>
>
> As discussed at the Digg-hosted hackathon.
> First off, this needs a better name, the idea isn't exactly like coprocessors
> from BigTable and this entry should be considered a stub for now (Stu and
> Marius should be able to provide more details).
> The idea is that for mutation operations, we should all the user to run a
> routine that has access to the "old" version of the data and the "new"
> version, and can take action.
> At a bare minimum, this should be capable of implementing distributed
> secondary indexes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
