> On Oct 6, 2021, at 8:07 AM, Jonathan Ellis wrote:
>
> I would love to see CLs simplified. Even without user-provided CL we
> almost certainly have too many. Providing a migration path is the hard
> part.
+1 on deprecating consistency levels. Migration path is easy for most
use-cases. Some n
Hey Lorina,
First of all - thank you so much for all the work done by you and the rest
of the people! The website and the docs are our front door as a project!
+1 on your proposal. My understanding is we need 1)+5) and then everything
else will be able to roll out and more people will be able to
Hi folks,Thanks for discussion on this proposal, and also to Benedict who’s
been fielding questions on the list!I’d like to restate the goals and problem
statement captured by this proposal and frame context.Today, lightweight
transactions limit users to transacting over a single partition. Thi
Jonathan,
This work will only determine Cassandra’s future if no other contributors
choose to take a different route in future. If in future the community decides
this work is incompatible with its direction, it remains in the community’s
power to remove the facility, or to make it optional.
O
On Wed, Oct 6, 2021 at 8:48 AM bened...@apache.org
wrote:
> That’s probably not a good reason here, and I agree that overloading
> consistency level feels wrong. I hope we will retire user-provided
> consistency levels over the coming year or two, which is another good
> reason not to begin enhan
The problem that I keep pointing out is that you've created this CEP for
Accord without first getting consensus that the goals and the tradeoffs it
makes to achieve those goals (and that it will impose on future work around
transactions) are the right ones for Cassandra long term.
At this point I'
The problem with dropping a patch on Jira is that there is no opportunity to
point out problems, either with the fundamental approach or with the specific
implementation. So please point out some problems I can engage with!
From: Jonathan Ellis
Date: Wednesday, 6 October 2021 at 15:48
To: dev
On Wed, Oct 6, 2021 at 9:21 AM bened...@apache.org
wrote:
> The goals of the CEP are stated clearly, and these were the goals we had
> going into the (multi-month) research project we undertook before proposing
> this CEP. These goals are necessarily value judgements, so we cannot expect
> that e
Hello all,
The changes in CircleCI proposed in the previous messages are implemented
in CASSANDRA-16882. They try to include the feedback from both the
reviewers and the Slack discussion at
https://the-asf.slack.com/archives/CK23JSY2K/p1631627458109000.
The patch modifies the CircleCI config to h
The goals of the CEP are stated clearly, and these were the goals we had going
into the (multi-month) research project we undertook before proposing this CEP.
These goals are necessarily value judgements, so we cannot expect that everyone
will agree that they are optimal.
So far you have not en
This is a very good point. I forget the reason we settled on consistency
levels, I assume it was due to simplicity of the solution, as deploying support
for a new protocol-level change is more involved.
That’s probably not a good reason here, and I agree that overloading
consistency level feels
On Wed, Oct 6, 2021 at 8:37 AM Paulo Motta wrote:
>
> This sounds like a great feature!
I agree, this is going to be very useful.
> I wonder if Consistencylevel is the best way to expose this to users
> though, can't we implement this via another driver/protocol option ? Ie.
> "delay_enabled" fl
I've repeatedly explained why I'm unhappy: instead of starting with a
discussion of what API and tradeoffs we should make to get that, this CEP
starts with a protocol and asks us to figure out what API we can build with
it.
Of course by API I mean, what kinds of CQL and SQL operations we can
perfo
This sounds like a great feature!
I wonder if Consistencylevel is the best way to expose this to users
though, can't we implement this via another driver/protocol option ? Ie.
"delay_enabled" flag that would be a modifier to an existing CL.
If we decide to go the CL route, I wonder if this isn't
Hi Everyone,
This is a modest user-facing feature that I want to highlight in case anyone
has any input. In order to validate if a real cluster may modify its topology
or consistency level (e.g. from local to global), this ticket introduces a
facility for injecting latency to internode messages
Thanks Lorina for all your work.
+1 Your proposal makes sense to me.
Le mer. 6 oct. 2021 à 00:34, Lorina Poland a écrit :
> This is a discussion about how to tackle getting the docs “fixed”.
>
> As many of you know, I started months ago to convert the Apache Cassandra
> in-tree docs
> from reSt
We have discussed the API at length in this thread. The API primarily involves
the semantics of the transactions, as besides this the API of a transaction is
simply:
Result perform(Transaction transaction)
As discussed in follow-up to that email, a prototype API is specified alongside
the prot
17 matches
Mail list logo
