[jira] [Commented] (CASSANDRA-1311) Triggers

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492827#comment-13492827 ] 

Jonathan Ellis commented on CASSANDRA-1311:
-------------------------------------------

Update: CASSANDRA-4285 is done for Cassandra 1.2.  This takes care of the main architectural obstacle for coordinator-based triggers as I outlined above:

bq. Triggers would be allowed to turn a write into a batch, or a batch into a modified batch.

E.g., in the twissandra example, when a user adds a tweet, you could read his followers list and add an insert into each of their timelines to the batch.

So here's what I think could be accomplished fairly easily:

{{code}}
public interface ITrigger
{
    public Collection<RowMutation> augment(RowMutation update);
}
{{code}}

Hook this in to the StorageProxy mutation path; if it returns more than one row, switch to mutateAtomic if we're not already part of an atomic batch.  If it returns none, skip it.

Commentary:
- Each row of a batch would be augmented individually, but all the trigger modifications together would be part of the same final batch.
- Returning the row unmodified is expected to be common
- Splitting this up into a "should we augment" method first is tempting but I suspect it would result in inefficiency between the "should we" and "make it so" calls.  Hacking state in with threadlocals would be clunky, better to leave it a single method.
- All triggers are "BEFORE" triggers, "AFTER" is tougher because of the batchlog semantics
- Ultimately it would be nice to have a "real" trigger definition language (possibly pluggable, like postgresql's), but I think that should be a separate ticket; our minimum viable product is, {{CREATE TRIGGER ON table EXECUTE 'com.my.company.TriggerClass'}}
- This ticket should include that for CQL and an equivalent method for Thrift.
                
> Triggers
> --------
>
>                 Key: CASSANDRA-1311
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Maxim Grinev
>             Fix For: 1.3
>
>         Attachments: HOWTO-PatchAndRunTriggerExample.txt, HOWTO-PatchAndRunTriggerExample-update1.txt, ImplementationDetails.pdf, ImplementationDetails-update1.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt
>
>
> Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation.
> Please find the motivation, triggers description and list of applications:
> http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
> An example of using triggers for indexing:
> http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
> Implementation details are attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira