cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-1311) Triggers
Date Wed, 07 Nov 2012 23:42:17 GMT

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

Jonathan Ellis edited comment on CASSANDRA-1311 at 11/7/12 11:42 PM:
---------------------------------------------------------------------

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.
                
      was (Author: jbellis):
    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

Mime
View raw message