You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2010/08/13 20:50:19 UTC

[jira] Commented: (CASSANDRA-1311) Support (asynchronous) triggers

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

Stu Hood commented on CASSANDRA-1311:
-------------------------------------

> Faster storage of "dangling" triggers at a slave node
I mentioned to Maxim at the summit that I think persisting the dangling triggers to the system tables is a good idea, because it preserves the guarantee that a full power loss to the cluster does not lose data. I imagine that it should be possible to gain the performance back somehow, since persisting to disk only requires additional writes (and should only read in node-failure cases).

Otherwise, I really like the architecture of this change, and only have minor suggestions:
* findTriggers is much too deeply nested: also, I'd like to see the bufferSize logic contained there moved into a maybeDrainNotificationBuffer method, or something.
* I'm not sure Arrays.hashCode is a strong enough indicator of uniqueness: you might want to switch to MD5
* TriggerSlave.deletedTriggers looks fragile (needs to expire old deletions), but switching back to using the system table would resolve that

> Support (asynchronous) triggers
> -------------------------------
>
>                 Key: CASSANDRA-1311
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Contrib
>            Reporter: Maxim Grinev
>             Fix For: 0.8
>
>         Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt, HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf, ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.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.
-
You can reply to this email to add a comment to the issue online.