Re: State of triggers

No problem, distributed systems are hard to reason about, I got caught many times in the past On Sun, Mar 5, 2017 at 9:23 AM, benjamin roth wrote: > Sorry. Answer was to fast. Maybe you are right. > > Am 05.03.2017 09:21 schrieb "benjamin roth" : > > > No.

Re: State of triggers

Not maybe. You are absolutely right. Bad idea. Hmpf. Am 05.03.2017 09:23 schrieb "benjamin roth" : > Sorry. Answer was to fast. Maybe you are right. > > Am 05.03.2017 09:21 schrieb "benjamin roth" : > >> No. You just change the partitioner. That's all >> >> Am

Re: State of triggers

There is a German saying: Sometimes you don't see the woods because of the lots of trees. Am 05.03.2017 09:25 schrieb "DuyHai Doan" : > No problem, distributed systems are hard to reason about, I got caught many > times in the past > > On Sun, Mar 5, 2017 at 9:23 AM,

Re: State of triggers

Sorry. Answer was to fast. Maybe you are right. Am 05.03.2017 09:21 schrieb "benjamin roth" : > No. You just change the partitioner. That's all > > Am 05.03.2017 09:15 schrieb "DuyHai Doan" : > >> "How can that be achieved? I haven't done "scientific

Re: State of triggers

No. You just change the partitioner. That's all Am 05.03.2017 09:15 schrieb "DuyHai Doan" : > "How can that be achieved? I haven't done "scientific researches" yet but I > guess a "MV partitioner" could do the trick. Instead of applying the > regular partitioner, an MV

Re: State of triggers

"How can that be achieved? I haven't done "scientific researches" yet but I guess a "MV partitioner" could do the trick. Instead of applying the regular partitioner, an MV partitioner would calculate the PK of the base table (which is always possible) and then apply the regular partitioner." The

Re: State of triggers

While I was reading the MV paragraph in your post, an idea popped up: The problem with MV inconsistencies and inconsistent range movement is that the "MV contract" is broken. This only happens because base data and replica data reside on different hosts. If base data + replicas would stay on the

Upgrade the jna version to 4.3.0

Hi All, Could you please upgrade the jna version present in the github cassandra location : https://github.com/apache/cassandra/blob/trunk/lib/jna-4.0.0.jar to below latest version - 4.3.0 - http://repo1.maven.org/maven2/net/java/dev/jna/jna/4.3.0/jna-4.3.0-javadoc.jar . Let me know the

Re: Upgrade the jna version to 4.3.0

Hi Amit, Can you open a Jira for that? Also we can figure out which branches to target for the upgrade on the Jira. Thanks, Jason On Sun, Mar 5, 2017 at 08:25 Amitkumar Ghatwal wrote: > > > Hi All, > > Could you please upgrade the jna version present in the github

Re: Upgrade the jna version to 4.3.0

Hi Jason, I have created a JIRA ticket : https://issues.apache.org/jira/browse/CASSANDRA-13300 for this upgrade activity . Please do let me know when the jna version will be upgraded on github -https://github.com/apache/cassandra/blob/trunk/lib/ . Regards, Amit From: Jason Brown