Re: [DISCUSS] CEP-45: Mutation Tracking

So the ids themselves are in the memtable and are accessible as soon as they’re written, and need to be for the read path to work. We’re not able to reconcile the ids until we can guarantee that they won’t be merged with unreconciled data, that’s why they’re flushed before reconciliation. > On

Re: [DISCUSS] Usage of "var" instead of types in the code

I remain +1 to allow in tests. Kind Regards, Brandon On Thu, Jan 9, 2025 at 3:20 PM David Capwell wrote: > > +1 to allow in tests > > On Jan 9, 2025, at 10:58 AM, Caleb Rackliffe wrote: > > +1 to allowing in tests for now > > On Wed, Jan 8, 2025 at 12:51 PM Mick Semb Wever wrote: >> >> >> Jump

Re: [DISCUSS] Usage of "var" instead of types in the code

+1 to allow in tests > On Jan 9, 2025, at 10:58 AM, Caleb Rackliffe wrote: > > +1 to allowing in tests for now > > On Wed, Jan 8, 2025 at 12:51 PM Mick Semb Wever > wrote: >> >> Jumping in, I'm ok to allow it in tests for a trial period too. I would >> imagine in tes

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.0 (2nd attempt)

+1 (nb) Le jeu. 9 janv. 2025 à 17:21, Sylwester Lachiewicz a écrit : > +1(nb) > > czw., 9 sty 2025, 17:13 użytkownik Josh McKenzie > napisał: > >> +1 >> >> On Wed, Jan 8, 2025, at 11:59 PM, Tolbert, Andy wrote: >> >> +1 (nb) >> >> On Wed, Jan 8, 2025 at 8:22 PM Chris Lohfink >> wrote: >> >> +

Re: [DISCUSS] Usage of "var" instead of types in the code

+1 to allowing in tests for now On Wed, Jan 8, 2025 at 12:51 PM Mick Semb Wever wrote: > > Jumping in, I'm ok to allow it in tests for a trial period too. I would > imagine in test methods especially it's of much less concern, where the > code is much simpler to read, and also safer to change t

Re: [DISCUSS] CEP-45: Mutation Tracking

> We also can't remove mutation ids until they've been reconciled, so in the > simplest implementation, we'd need to flush a memtable before reconciling, > and there would never be a situation where you have purgeable mutation ids in > the memtable. Got it. So effectively that data would be unre

Re: [DISCUSS] CEP-45: Mutation Tracking

Hi Josh, You can think of reconciliation as analogous to incremental repair. Like incremental repair, you can't mix reconciled/unreconciled data without causing problem. We also can't remove mutation ids until they've been reconciled, so in the simplest implementation, we'd need to flush a memt

Re: [DISCUSS] CEP-45: Mutation Tracking

Hi Guo and Chris >> Does it support changing the table to support mutation tracking through >> ALTER TABLE if it does not support mutation tracking before? Yes, migration for existing keyspaces/tables will be supported. >> Do you think that keyspace_inherit (or other keywords that clearly expl

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.0 (2nd attempt)

+1 Kind Regards, Brandon On Wed, Jan 8, 2025 at 4:15 PM Bret McGuire wrote: > > Greetings all! > > >I’m proposing the Cassandra Java Driver 3.12.0 for release. This > represents a second attempt at releasing this version; an earlier attempt > failed due to a staging issue. > > > sha1: 1a9

Re: [DISCUSS] CEP-45: Mutation Tracking

Question re: Log Truncation (emphasis mine): > When the cluster is operating normally, logs entries can be discarded once > they are older than the last reconciliation time of their

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.0 (2nd attempt)

+1(nb) czw., 9 sty 2025, 17:13 użytkownik Josh McKenzie napisał: > +1 > > On Wed, Jan 8, 2025, at 11:59 PM, Tolbert, Andy wrote: > > +1 (nb) > > On Wed, Jan 8, 2025 at 8:22 PM Chris Lohfink wrote: > > +1 > > On Wed, Jan 8, 2025 at 4:14 PM Bret McGuire > wrote: > > Greetings all! > >I’m pro

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.0 (2nd attempt)

+1 On Wed, Jan 8, 2025, at 11:59 PM, Tolbert, Andy wrote: > +1 (nb) > > On Wed, Jan 8, 2025 at 8:22 PM Chris Lohfink wrote: >> +1 >> >> On Wed, Jan 8, 2025 at 4:14 PM Bret McGuire wrote: >>> Greetings all! >>> >>> >>>I’m proposing the Cassandra Java Driver 3.12.0 for release. This >>>

Re: [DISCUSS] CEP-45: Mutation Tracking

Is this something we can disable? I can see scenarios where this would be strictly and severely worse then existing scenarios where we don't need repairs. ie short time window data, millions of writes a second that get thrown out after a few hours. If that data is small partitions we are nearly dou