+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
>> represents a second attempt at releasing this version; an earlier attempt
>
After a brief understanding, there are 2 questions from me, If I ask
something inappropriate, please feel free to correct me :
1、 Does it support changing the table to support mutation tracking through
ALTER TABLE if it does not support mutation tracking before?
2、
> Available options for tables
+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
> represents a second attempt at releasing this version; an earlier attempt
> failed due to a staging issue.
>
> sha1: 1a96d27130ea43ed5762c4f7b7cc182eb
Your pagination case is not a violation of any guarantees Cassandra makes. It has never made guarantees across multiple queries.Trying to have MVCC/consistent data across multiple queries is a very different issue/problem from this CEP. If you want to have a discussion about MVCC I suggest creatin
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: 1a96d27130ea43ed5762c4f7b7cc182eb24f8952
git: https://github.com/apache/cassandra-java-driver/tree/3.
JD, the fact that pagination is implemented as multiple queries is a design
choice. A user performs a query with fetch size 1 or 100 and they will get
different behavior.
I'm not asking for anyone to implement MVCC. I'm asking for the docs
around this to be correct. We should not use the term g
Heads up for everyone: I am cancelling this vote due to an issue with
how I staged the artifacts in Nexus. I'll be putting up a new request for
a vote shortly.
On Fri, Jan 3, 2025 at 2:54 PM Bret McGuire wrote:
> Greetings all!
>
>I’m proposing the Cassandra Java Driver 3.12.0 for releas
>> 2) What is a granularity of storing mutation ids in memtable, is it per
cell?
It would be per-partition
I suppose we have a kind of trade-off here: granularity of such metadata vs
probability of read repair in some cases.. An example: if there is a big
enough partition (like a time slot) to whi
> It's true that we can't offer multi-page write atomicity without some
sort of MVCC. There are a lot of common query patterns that don't involve
paging though, so it's not like the benefit of fixing write atomicity would
only apply to a small subset of carefully crafted queries or something.
Sure
Thanks Dimitry and Jon, answers below
> 1) Is a single separate commit log expected to be created for all tables with
> the new replication type?
The plan is to still have a single commit log, but only index mutations with a
mutation id.
> 2) What is a granularity of storing mutation ids in m
Very cool! I'll need to spent some time reading this over. One thing I
did notice is this:
> Cassandra promises partition level write atomicity. This means that,
although writes are eventually consistent, a given write will either be
visible or not visible. You're not supposed to see a partially
Hello Blake, thank you a lot for sharing the CEP, it looks really promising
and should address many of the current pain points!
I have a few questions to clarify:
1) Is a single separate commit log expected to be created for all tables
with the new replication type?
2) What is a granularity of stor
With two binding votes, this vote has failed.
On Wed, Nov 13, 2024 at 4:03 PM Brandon Williams
wrote:
>
> Proposing the test build of Cassandra 5.0.3 for release.
>
> sha1: b9a5d15deec81295113cdc703d5acda423d8a688
> Git: https://github.com/apache/cassandra/tree/5.0.3-tentative
> Maven Artifacts:
With two binding votes, this vote has failed.
On Wed, Nov 13, 2024 at 3:31 PM Brandon Williams
wrote:
>
> Proposing the test build of Cassandra 4.1.8 for release.
>
> sha1: 77cc238deec25a15a40970f23442ebb83d495ab9
> Git: https://github.com/apache/cassandra/tree/4.1.8-tentative
> Maven Artifacts:
Hello dev@,
We'd like to propose CEP-45: Mutation Tracking for adoption by the community.
CEP-45 proposes adding a replication mechanism to track and reconcile
individual mutations, as well as processes to actively reconcile missing
mutations.
For keyspaces with mutation tracking enabled, the
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 to types later on.
On Wed, 8 Jan 2025 at 16:46, Josh McKenzie wrote:
> I would like to remove th
> I would like to remove this altogether from tests and ban it too in a week or
> two.
I took "ban it too in a week or two" as an indicator of intent. Looks like
that's not what you intended.
I believe at least David and I both use and would like to continue using "var"
when working on tests. A
Indeed, we don't. That's what "I would like to" means.
I asked additional questions on 5th November wanting to know more about
people advocating for vars in tests -> no response.
I also do not see any vars added since then.
So, what do we have vars enabled for?
1) not enough time has passed, me
18 matches
Mail list logo
