Re: custom validation before replication

2017-11-16 Thread Jeff Jirsa
What you're wanting really isn't supported/available, but you could probably extend cassandra to do this with some work. Doing this at replication time is the wrong point, though - you want to do it before the mutation is applied locally, so triggers are still the closest to the right point as

Re: custom validation before replication

2017-11-16 Thread Jon Haddad
Looks like you’ve got this thread going on the user & dev ML. This list is the dev one, and is meant for discussion of the Cassandra project. Would everyone mind replying to the thread of the same name on the user list instead? > On Nov 16, 2017, at 1:36 PM, Abdelkrim Fitouri

Re: custom validation before replication

2017-11-16 Thread Abdelkrim Fitouri
ok please find bellow an example: Lets suppose that i have a cassandra cluster of 4 nodes / one DC / replication factor = 4, So in this architecture i have on full copy of the data on each node. Imagine now that one node have been hacked and in some way with full access to cqlsh session, if data

RE: custom validation before replication

2017-11-16 Thread Abdelkrim Fitouri
Trigger does not resolve my problem because it is not a format validation issue but an integrity constraint ... My purpose is to check data integrity before replication, by returning an error and killing the service, so i am killing the node that is supposed to replicate data after a write action

Re: custom validation before replication

2017-11-16 Thread Jeff Jirsa
Going to hate myself for this, but check out the trigger interface. https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/triggers/ITrigger.java Pay attention to the note that says the API is in beta and subject to change. It's had that note for many years, which

RE: custom validation before replication

2017-11-16 Thread Jacques-Henri Berthemet
Hi, You can't prevent the replication because if you manage to return a failure the other node will keep trying to send the data. What would be more relevant is to prevent the modification in the first place. You could try to implement a custom trigger and load it in Cassandra: