[
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
