cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oren Yekutieli <>
Subject RE: FW: Cassandra trigger to send notifications
Date Mon, 19 Dec 2016 20:57:05 GMT
Thank you both Matija and Eric.
I have read somewhere about CDC but I didn’t know that it is already released.
I also didn’t find good documentation of it except for the design doc and Jira ticket, where
in both cases it is hard to know what really was released.
As a newbie to Cassandra I will probably do need a more ‘user friendly’ CDC documentation.
Is it available somewhere?


From: Eric Stevens []
Sent: Saturday, December 17, 2016 12:32 AM
Subject: Re: FW: Cassandra trigger to send notifications

You probably want to look at change data capture rather than triggers:

Be aware that one of your criteria regarding operation order is going to be very difficult
to guarantee due to eventual consistency.

On Fri, Dec 16, 2016, 2:43 AM Matija Gobec <<>>
Hi Oren,

I've spent a reasonable time working out triggers and I would say that your best bet is doing
this in the app.
Just publish a rabbitmq message from the app when you execute a statement.
If your goal is to have an audit then try batch writing data to the tables and delta to their
audit counterparts.


On Fri, Dec 16, 2016 at 9:14 AM, Oren Yekutieli <<>>

In a Cassandra cluster I want to push a notification to rabbitmq whenever a change (insert/update/delete)
was made to some Cassandra tables, with the following requirements:
The notifications should:

1.      Be ordered in the same order the changes were stored.

2.      Be sent only if the change was (or going to be) committed successfully.
And in case of insert/update:

3.      Include all the row values.

4.      Indicate what values were changed.

I’m trying to figure out if Cassandra triggers are the correct way to go.
According to,
one of the potential use cases for triggers is:
•        >> implementing alerts/notifications
I also played a bit with the example given here:
and from what I read and learned so far I assume that:
Regarding #1, I doubt if the notification order can be kept since the trigger is invoked on
the coordinator node while there are multiple clients that can connect to the various cluster
nodes (coordinators).
Regarding #2, I’m not sure that notification will be sent only for changes that are going
to be committed successfully since the trigger is invoked before the change is being applied.
Regarding #3, I seen that this requirement is fulfilled.
Regarding #4, I didn’t find a way to figure out what values are actually changed, without
re-reading the current (old) values from the table which of course impose a significant performance

Are my assumptions correct?
If yes then triggers are not the right approach. What other ways can be taken?


View raw message