[ 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.