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
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
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
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
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
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"
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
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
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
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
+1
Dinesh
> On Oct 5, 2021, at 7:27 PM, Joshua McKenzie wrote:
>
> +1
>
>> On Tue, Oct 5, 2021 at 2:15 PM Brandon Williams wrote:
>>
>> +1
>>
>>> On Tue, Oct 5, 2021 at 11:47 AM Oleksandr Petrov
>>> wrote:
>>>
>>> Proposing the test build of in-jvm dtest API 0.0.10 for release.
>>>
>>>
+1
On Tue, Oct 05, 2021 at 06:47:10PM +0200, Oleksandr Petrov wrote:
> Proposing the test build of in-jvm dtest API 0.0.10 for release.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.10
>
> Candidate SHA:
>
13 matches
Mail list logo
