Just so you know you should probably apply the [jira] [Commented] (*CASSANDRA*-6790) *Triggers* are broken in trunk *...*<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCcQFjAA&url=https%3A%2F%2Fwww.mail-archive.com%2Fcommits%40cassandra.apache.org%2Fmsg80563.html&ei=Hd4dU-7IGOTq0wHT-YHQCw&usg=AFQjCNELJe3hmp_gJWXih91S1CL2f4KLtQ&sig2=xJ5h_7FqX-qZ6iVgXwpr-g&bvm=bv.62578216,d.dmQ>
patch because triggers are currently only called on batch_mutate and will fail if called on insert. On Mon, Mar 10, 2014 at 10:50 AM, DE VITO Dominique < dominique.dev...@thalesgroup.com> wrote: > > You should be able to achieve what you're looking for with a trigger vs. > a modification to the core of Cassandra. > > > > > > > http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-0-prototype-triggers-support > > > > Well, good point. > > > > It leads to the question: (a) are triggers executed on all (local+remote) > coordinator nodes (and then, N DC => N coordinator nodes => N executions of > the triggers) ? > > > > (b) Or are triggers executed only on the first coordinator node, and not > the (next/remote DC) coordinator nodes ? > > > > My opinion is (b), and in that case, triggers won't do the job. > > (b) would make sense, because the first coordinator node would augment > original row mutations and propagate them towards other coordinator nodes. > Then, no need to execute triggers on other (remote) coordinator nodes. > > > > Is there somebody knowing about trigger execution : is it (a) or (b) ? > > > > Thanks. > > > > Dominique > > > > > > > > > > On Mon, Mar 10, 2014 at 10:06 AM, DE VITO Dominique < > dominique.dev...@thalesgroup.com> wrote: > > > On 03/10/2014 07:49 AM, DE VITO Dominique wrote: > > > > If I update a data on DC1, I just want apps "connected-first" to DC2 > > > > to be informed when this data is available on DC2 after replication. > > > > > > If I run a SELECT, I'm going to receive the latest data per the read > conditions (ONE, TWO, QUORUM), regardless of location of the client > connection. If using > network aware topology, you'll get the most current > data in that DC. > > > > > > > When using Thrift, one way could be to modify CassandraServer class, > > > > to send notification to apps according to data coming in into the > > > > coordinator node of DC2. > > > > > > > > Is it "common" (~ the way to do it) ? > > > > > > > > Is there another way to do so ? > > > > > > > > When using CQL, is there a precise "src code" place to modify for the > > > > same purpose ? > > > > > > Notifying connected clients about random INSERT or UPDATE statements > that ran somewhere seems to be far, far outside the scope of storing data. > Just configure your client to SELECT in the manner that you need. > > > > > > I may not fully understand your problem and could be simplifying things > in my head, so feel free to expand. > > > > > > -- > > > Michael > > First of all, thanks for you answer and your attention. > > > > I know about SELECT. > > The idea, here, is to avoid doing POLLING regularly, as it could be easily > a performance nightmare. > > The idea is to replace POLLING with PUSH, just like in many cases like > SEDA architecture, or CQRS architecture, or continuous querying with some > data stores. > > > > So, following this PUSH idea, it would be nice to inform apps connected to > a preferred DC that some new data have been replicated, and is now > "available". > > > > I hope it's clearer. > > > > Dominique > > > > >
