Re: server side describe

> scope creep. I think it is unfair to label this scope creep; it would have to be newly considered for 4.0 for it to fall under that umbrella. I don't personally mind if it lands, but this was discussed at length on multiple occasions over the past year, and only stalled because of a

Re: Apache Cassandra logo

I’m onboard. Feels like the project is about the right age to have a mid-life crisis and try to spice things up a bit with a new logo. From: Patrick McFadin Date: Friday, 11 June 2021 at 17:44 To: dev@cassandra.apache.org Subject: Re: Apache Cassandra logo I'm going to call this out and take

Re: Are we ready for 4.0.0 (GA) ?

A rate of 4/30 is a rate of 13% true bugs, which worries me with respect to our promise of shipping a bug-free GA. In past releases we have ensured no flaky tests, I think. That said, I’ve not had the time to contribute to the fixing of flaky tests, so I’ll leave the decision to those who

Re: Additions to Cassandra ecosystem page?

Under Cloud Offerings, are we comfortable implicitly endorsing “API compatible” offerings that aren’t actually Cassandra, and also don’t (as far as I am aware) fully support Cassandra functionality? Should we at least mention that this is the case? From: Melissa Logan Date: Tuesday, 22 June

Re: Additions to Cassandra ecosystem page?

r requirements. > > 1 small update I would suggest. It seems like Datastax Spring Boot entry > would go in development frameworks as opposed to the sidecar section. > > On Tue, Jun 22, 2021, 5:39 PM bened...@apache.org > wrote: > > > Under Cloud Offerings, are we comfor

Re: Additions to Cassandra ecosystem page?

+1 From: Brandon Williams Date: Wednesday, 23 June 2021 at 15:44 To: dev@cassandra.apache.org Subject: Re: Additions to Cassandra ecosystem page? On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie wrote: > > The obvious core responsibility of the website should be to ASLv2 > permissively licensed

Re: Are we ready for 4.0.0 (GA) ?

the code. Would it make sense to say: "Let's give us 1 or 2 weeks to test RC-2. If no blocker shows up we can release 4.0 GA" ? Le mar. 15 juin 2021 à 12:25, bened...@apache.org a écrit : > That popularity line is a lot more stable than I would have expected, > honest

Re: [DISCUSSION] Should we mark DROP COMPACT STORAGE as experimental

This seems reasonable to me, but it raises a question of roadmap. My understanding is that we are deprecating compact storage, and will remove it in a future release (or have already partially removed it? I forget). Do these issues then constitute a blocking issue for GA, or do we modify our

[DISCUSS] CEP-10: Cluster and Code Simulations

Proposal for a mechanism to evaluate whole clusters, or individual classes, with a deterministically pseudorandom ordering of all thread and message events. https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10%3A+Cluster+and+Code+Simulations Evaluating the correctness of distributed

Re: Obfuscation of passwords in audit loging, in or not in 4.0?

I think it can be argued that this is a pretty serious bug for a newly introduced feature, and qualifies for inclusion in an RC, but I don’t personally have a strong opinion on if this should happen. I can’t imagine how this would be an _exception_ for inclusion in 4.0.1 though. From: Mick

Re: [DISCUSS] Clarifying the CEP process

That’s how I understand the process, yes. Voting to accept the CEP just indicates that the broad strokes painted by the CEP are acceptable to the community, and a patch can be brought forward with the expectation that it will be accepted once it meets the other criteria for acceptance. From:

Re: [DISCUSS] Clarifying the CEP process

I think that’s a bit extreme – it seems perfectly fine to comment on Jira, but high level discussions around scope, goals and potential confounders should ideally happen on the DISCUSS thread. It’s a difficult balancing act, choosing the venue for a discussion, so let’s not censure people

Re: Additions to Cassandra ecosystem page?

l Em ter., 29 de jun. de 2021 às 04:48, Benjamin Lerer escreveu: > If I have to choose between the four choices that you proposed I would then > choose (1) List no alternative offerings at all. > > Le mar. 29 juin 2021 à 09:34, bened...@apache.org a > écrit : > > >

Re: Additions to Cassandra ecosystem page?

I don’t think it is intractable to come up with a definition that we use for inclusion. 1. List no alternative offerings at all. 2. List only those offerings that deploy precisely a released version of Cassandra. 3. List only those offerings that deploy precisely a released version of

Re: [DISCUSS] CEP 14: Paxos Improvements

dict :D Patrick On Thu, Aug 19, 2021 at 1:50 AM bened...@apache.org wrote: > Hi Jeremy, > > That’s a great question, and the answer is that we shouldn’t compare the > two as they aren’t in conflict. The goal of this work is only to improve > the existing Paxos implementation – th

Re: [DISCUSS] CEP 14: Paxos Improvements

g throughput beyond a level that > would be afforded by the latency reduction alone. > > - Better safety among range movements: Electorate verification during range > movements provides a stronger assertion of linearizability via assurance of > the set of instances voting on a

Re: [DISCUSS] CEP 14: Paxos Improvements

CLs defined for tables is a worthy enhancement, I wonder if it should be a ‘default CL’ which can additionally be overridden by queries? In any event I feel I’ve hijacked your thread enough, but thank you again for the warm welcome and the interesting discussion! > On 20 Aug 2021, at 7:04

[DISCUSS] CEP 14: Paxos Improvements

RE: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements I’m proposing this CEP for approval by the project. The goal is to both improve the performance of LWTs and to ensure their correctness across a range of scenario like range movements. This work builds upon

[VOTE] CEP-14: Paxos Improvements

Hi everyone, I’m proposing this CEP for approval. Proposal: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements Discussion: https://lists.apache.org/thread.html/r1af3da2d875ef93479e3874072ee651f406b96c915759c7968d3266e%40%3Cdev.cassandra.apache.org%3E The vote

Re: [VOTE] CEP-14: Paxos Improvements

27 Aug 2021, at 20:48, bened...@apache.org wrote: > > > > Hi everyone, I’m proposing this CEP for approval. > > > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements > > Discu

Re: [DISCUSS] CEP 14: Paxos Improvements

I’ll move this to a vote in a day or so, assuming no further discussion. From: Jeff Jirsa Date: Monday, 23 August 2021 at 06:46 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP 14: Paxos Improvements > On Aug 22, 2021, at 7:25 PM, Miles Garnsey wrote: > >  >> >> The problem is that

Re: [VOTE] CEP-11: Pluggable memtable implementations

FYI, as formulated in the project governance document (though, as ever, clarity could be improved) for CEP votes from committers have equal weight to those from the PMC. From: Branimir Lambov Date: Tuesday, 24 August 2021 at 12:25 To: dev@cassandra.apache.org Subject: Re: [VOTE] CEP-11:

Re: [DISCUSS] CEP 14: Paxos Improvements

rizability via assurance of > the set of instances voting on a transaction. > > – Scott > > > From: bened...@apache.org > Sent: Wednesday, August 18, 2021 2:31 PM > To: dev@cassandra.apache.org > Subject: [DISCUSS] CEP 1

Re: [VOTE] CEP-11: Pluggable memtable implementations

+1 From: Brandon Williams Date: Thursday, 19 August 2021 at 17:16 To: dev@cassandra.apache.org Subject: Re: [VOTE] CEP-11: Pluggable memtable implementations +1 On Thu, Aug 19, 2021 at 11:11 AM Branimir Lambov wrote: > > Hello everyone, > > I am proposing the CEP-11 (Pluggable memtable

Re: [DISCUSS] CASSANDRA-15234

o talk about this thread! To > > group or not to group; that is the question > > > > Personally I like grouping from an organization point of view so am in > > favor of that; though I will agree that it can be hard for some tools > (such > > as bash templating), but feel

Re: [DISCUSS] CASSANDRA-15234

Thanks for bringing this to the list Ekaterina! It’s worth noting that the two don’t have to be in conflict: we could offer two template yaml with the parameters grouped differently, for users to decide for themselves. The proposals primarily define parameter names differently, with my

Re: [DISCUSS] CEP-15: General Purpose Transactions

September 2021 at 14:06 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions On Tue, Sep 7, 2021 at 12:26 PM bened...@apache.org wrote: > > whether I should just* think of this as "better and more efficient LWT” > > So, the LWT concept is

Re: [DISCUSS] CEP-15: General Purpose Transactions

I am very intrigued by the paper and proposal. This looks excellent. Thanks Benedict, et all for putting this together! -Nate On Mon, Sep 6, 2021 at 2:33 AM bened...@apache.org wrote: > Wiki: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transa

Re: [DISCUSS] CEP-15: General Purpose Transactions

tely sounds like a nightmare from the user POV) but it isn't stated clearly. If replacement is indeed the intent, then I think there needs to be a plan for the upgrade path. If that's not the intent, then what? -- Sylvain On Wed, Sep 15, 2021 at 12:09 PM bened...@apache.org wrote: > Ok, so th

Re: [DISCUSS] CEP-15: General Purpose Transactions

ly commenting on it. > > Em ter., 14 de set. de 2021 às 17:30, bened...@apache.org < > bened...@apache.org> escreveu: > >> Has anyone had a chance to read the drafts, and has any feedback or >> questions? Does anybody still anticipate doing so in the near future? Or

Re: [DISCUSS] CEP-15: General Purpose Transactions

fluid right now and will > be rewritten / refactored multiple times over the next few months. > > Thanks, > > Blake > > > > On Sun, Sep 5, 2021 at 10:33 AM bened...@apache.org > > > wrote: > > > >> Wiki: > >> > https://cwiki.apache.org/c

Re: [DISCUSS] CEP-15: General Purpose Transactions

like single-shot transaction, it still begs the question what mechanism can consume read results and based on those impact the writes? Reading the CEP: Are the results of the Jepsen testing available too? (Or will be?) henrik On Sun, Sep 5, 2021 at 5:33 PM bened...@apache.org wrote: > Wiki:

Re: [DISCUSS] CASSANDRA-16922 CEP-10: Major Prerequisites (Phase 1)

It’s worth clarifying that CEP-10 has been broken up into phases, and this will be a roll-up branch for only the first portion. I think we should be cautious about how we approach the idea of feature branches, as there is significant overhead for everyone as branches grow - the CEP-10 and

Re: [DISCUSS] CEP-15: General Purpose Transactions

Has anyone had a chance to read the drafts, and has any feedback or questions? Does anybody still anticipate doing so in the near future? Or shall we move to a vote? From: bened...@apache.org Date: Tuesday, 7 September 2021 at 21:27 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15

Re: [DISCUSS] CEP-15: General Purpose Transactions

that the most suitable governance and set of committers/PMC members are those of the Apache Cassandra project itself. On Sep 14, 2021, at 3:53 PM, "bened...@apache.org" wrote: Hi Paulo, First and foremost, I believe this proposal in its current form focuses on the protocol details (HOW

Re: [DISCUSS] CEP-15: General Purpose Transactions

to evolve CQL sooner than later if there is the appetite. There are no concrete proposals to discuss, it would be brainstorming. Do people also generally agree this work warrants a distinct CEP, or would people prefer to see this developed under the same umbrella? From: bened...@apache.org

Re: [VOTE] CEP-13: Denylisting partitions

+1 From: Brandon Williams Date: Wednesday, 8 September 2021 at 17:57 To: dev@cassandra.apache.org Subject: Re: [VOTE] CEP-13: Denylisting partitions +1 On Wed, Sep 8, 2021 at 11:31 AM Sumanth Pasupuleti wrote: > > Hi everyone, > > I’m proposing this CEP for approval. > > Proposal: >

Re: [DISCUSS] CEP-15: General Purpose Transactions

not as hard as you might think. It is probably outside of the scope of this work, though the two would dovetail very nicely. From: Henrik Ingo Date: Tuesday, 7 September 2021 at 09:24 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions On Tue, Sep 7, 2021

[DISCUSS] CEP-15: General Purpose Transactions

Wiki: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transactions Whitepaper: https://cwiki.apache.org/confluence/download/attachments/188744725/Accord.pdf

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

AM, bened...@apache.org wrote: > >> I do think adding the ability to do “Cluster and Code Simulations” is a new >> feature. > > I don’t. I understand a feature to be a user-visible change, such as new > functionality, and it was on this basis I endorsed the release

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

nly be allowed in subsequent major versions, unless an explicit exception is granted. Em ter., 13 de jul. de 2021 às 07:11, bened...@apache.org < bened...@apache.org> escreveu: > Perhaps it’s worth looking forward at the roadmap that we plan to develop, > and consider whether such a

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

think adding the ability to do “Cluster and Code Simulations” is a new feature. -Jeremiah > On Jul 13, 2021, at 8:37 AM, bened...@apache.org wrote: > > Nothing we’re discussing constitutes a feature. We’re discussing stability > enhancements, and important bug fixes. > > I

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

, I am > convinced of its value. > > Thanks, > Sam > > > On 13 Jul 2021, at 09:20, bened...@apache.org wrote: > > > > Did anyone have any thoughts on this CEP, or shall I bring it forward > for a vote also? > > > > From: bened...@apache.org > &g

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations On Tue, Jul 13, 2021 at 7:31 AM bened...@apache.org wrote: > Furthermore, we introduced a significant performance regression in all lines > of the software by increasing the number of LWT round-trips. Unless

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

ssues. There are > still some issues during topologie changes (may be in some other scenarios). > > My understanding of Benedict's proposal is to fix paxos once and for all > without any performance regression. > > That goal makes total sense to me. "Where do we do that?&qu

Re: [VOTE] Release Apache Cassandra 4.0.0

Do we support aarch64? If we don’t we should continue with the release; if we do, we should (unfortunately) re-roll. I’m genuinely unsure if we officially support it or not, though. I see an earlier related thread, but no vote and no conclusion about supported architectures. From: Mick Semb

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

the correctness of difficult but critical systems is justification enough, whether or not we deliver a simple API as part of the CEP. From: bened...@apache.org Date: Tuesday, 13 July 2021 at 10:43 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations > Sho

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

Did anyone have any thoughts on this CEP, or shall I bring it forward for a vote also? From: bened...@apache.org Date: Thursday, 3 June 2021 at 20:19 To: dev@cassandra.apache.org Subject: [DISCUSS] CEP-10: Cluster and Code Simulations Proposal for a mechanism to evaluate whole clusters

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

> Should target release be 4.1. (not 4.0.x) ? No, in my opinion the target should be 4.0.x. We are reaching for a shippable trunk and this has no public API impacts. This work is IMO central to achieving a shippable trunk, either way. The only reason I do not target 3.x is that it would be too

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

-13981) From: bened...@apache.org Date: Tuesday, 13 July 2021 at 10:51 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations Ach, editing code in the email editor isn’t smart when editors all have different meanings for key combinations (accidentally hit send

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

sion to address that issue (e.g. 4.1). > > I am also against making the change in the 4.0 branch. > > Le mar. 13 juil. 2021 à 16:09, bened...@apache.org a > écrit : > > > My point is that we all have different premises we are working from. I > > don’t think you can

Re: [DISCUSS] Jira state for second reviewer

Perhaps “Awaiting Second Review”? It looks from the flow that this is more accurate, as a second reviewer could have been assigned but review could not yet have gotten underway? It’s unclear to me what you would do in this case – would it return to Patch Available, or sit in Needs Second

Re: [DISCUSS] Jira state for second reviewer

identify spots that need attention/help. I don’t disagree with you, I just think this is one additional point we have to consider separately. On Mon, 2 Aug 2021 at 10:17, bened...@apache.org wrote: > I was proposing substituting “Needs Second Reviewer” for “Awaiting Second >

Re: [DISCUSS] Jira state for second reviewer

it would be better after the ticket was in review for particular amount of time, alert/reminder to be sent to the reviewers. But probably we can also do both things for more visibility if we as a community want to. On Mon, 2 Aug 2021 at 10:02, bened...@apache.org wrote: > Perhaps “Awaiting Sec

Re: [DISCUSS] CASSANDRA-16767, CASSANDRA-16768, and CASSANDRA-16769 for 3.11.x

Hi Scott, I wonder if it’s possible that too few people who saw your email consider themselves sufficiently involved in this part of the codebase. People tend to keep quiet about stuff they don’t participate in deeply, which is why I haven’t responded – and I wonder if this might explain the

[RESULT] [VOTE] CEP-10: Cluster and Code Simulations

t; +1 nb > > > From: Sam Tunnicliffe > Sent: Tuesday, July 27, 2021 12:54 AM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] CEP-10: Cluster and Code Simulations > > +1 > >> On 26 Jul 2021, at 11:51, bened...@apache.org wrote: >> >> Proposing

Re: [DISCUSS] CEP-15: General Purpose Transactions

ill in the blanks. From: Jonathan Ellis Date: Friday, 24 September 2021 at 20:28 To: dev Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions Does anyone have notes for those of us who couldn't make the call? On Wed, Sep 22, 2021 at 1:35 PM bened...@apache.org wrote: > Hi everyone, > &

Re: Tradeoffs for Cassandra transaction management

Hi Alex, I hugely value and respect your input here, but I think in this case you may be mistaken. Postgres[1] makes explicit that subsequent SELECT statements may see different data, and SQL Server[2] does the same. I believe the Oracle documents you reference do the same, but are more

Re: Tradeoffs for Cassandra transaction management

meaningful detail? > > > On Oct 11, 2021, at 6:34 PM, Jonathan Ellis wrote: > > > > On Mon, Oct 11, 2021 at 5:11 PM bened...@apache.org > > > wrote: > > > >> If we want to fully unpack this particular point, as far as I can tell > >> claiming AN

Re: Tradeoffs for Cassandra transaction management

(like Calvin, and for distributed consensus protocols) to serialize their execution, unless I’m missing something. Otherwise I agree entirely with your email, now I’ve read it  From: bened...@apache.org Date: Wednesday, 13 October 2021 at 08:52 To: dev@cassandra.apache.org Subject: Re

Re: [IDEA] Read committed transaction with Accord

> It seems like potentially every statement now needs to go through the Accord > consensus protocol, and this could become expensive, where my goal was to design the simplest and most lightweight example thinkable. BUT for read-only Accord transactions, where I specifically also don't care about

Re: [DISCUSS] CEP-15: General Purpose Transactions

> In the context of Cassandra, I had actually assumed the Accord timestamp will > be used as the cell timestamp for each value? Isn't something like this > needed for compaction to work correctly too? Yes, though we are likely to apply some kind of compression to the timestamp, as global

Re: [DISCUSS] CEP-15: General Purpose Transactions

Date: Wednesday, 13 October 2021 at 15:50 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions On Wed, Oct 13, 2021 at 2:54 PM bened...@apache.org wrote: > I think this is a blurring of lines of systems however. I _think_ the > point Alex is making (corr

Re: Tradeoffs for Cassandra transaction management

for Cassandra transaction management On Mon, Oct 11, 2021 at 5:11 PM bened...@apache.org wrote: > If we want to fully unpack this particular point, as far as I can tell > claiming ANSI SQL would indeed require interactive transactions in which > arbitrary conditional work may be performed by

Re: Tradeoffs for Cassandra transaction management

known read/write set, as I outlined in the email to kick off this thread. On Sun, Oct 10, 2021 at 4:05 AM bened...@apache.org wrote: > Hi Jonathan, > > I will summarise my position below, that I have outlined at various points > in the other thread, and then I would be interested t

Re: Tradeoffs for Cassandra transaction management

Hi Jonathan, I will summarise my position below, that I have outlined at various points in the other thread, and then I would be interested to hear how you propose we move forwards. I will commit to responding the same day to any email I receive before 7pm GMT, and to engaging with each of

Re: [DISCUSS] CASSANDRA-15234

aintain doesn’t exist > > > > > > # remove comments and empty lines > > > $ egrep -v '^[[:space:]]*#|^[[:space:]]*$' conf/cassandra.yaml.doc > > > conf/cassandra.yaml > > > > > > We do this right now with conf/hotspot_compiler so as long as

Re: Tradeoffs for Cassandra transaction management

SQL with interactive transactions. I'd prefer to keep the discussion on the mailing list, thanks. On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org wrote: > Jonathan, > > Your request to separate consensus from execution is about as sensical as > asking for this separation in Paxos, o

Re: Save CircleCI resources with optional test jobs

I think this would be fine if there were a way for approval of later steps to trigger the build automatically. As it is we have to traverse the dependency graph manually, which is a bit weird. I can’t figure out a way to do this with the CircleCI API however. It might be a feature request, and

Re: Save CircleCI resources with optional test jobs

current workflow and approval required > but if it is not acceptable to others and skipping the build approval click > is what others would prefer, I will open a ticket to restore that part. > Please let me know and one more time, apologize for missing your email, > Alex. > > Best r

[VOTE] CEP-15: General Purpose Transactions

Hi everyone, I would like to start a vote on this CEP, split into three sub-decisions, as discussion has been circular for some time. 1. Do you support adopting this CEP? 2. Do you support the transaction semantics proposed by the CEP for Cassandra? 3. Do you support an incremental approach to

Re: Tradeoffs for Cassandra transaction management

ty like LWT" is also reasonable) and (2) SQL with interactive transactions. I'd prefer to keep the discussion on the mailing list, thanks. On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org wrote: > Jonathan, > > Your request to separate consensus from execution is about as sensi

Re: Tradeoffs for Cassandra transaction management

f engaging in hypotheticals around how "we could enhance Accord with X." On Thu, Oct 14, 2021 at 12:46 PM bened...@apache.org wrote: > > Calvin supports arbitrarily complex transactions (included dependent > statements and indexed reads and writes), executed in parallel, with >

Re: [VOTE] CEP-15: General Purpose Transactions

(3 binding +1 votes and no binding > vetoes). The vote should remain open for 72 hours." > > No provision is made for declaring a CEP, or part of it, to be subject to > a simple majority vote simply by claiming it's directional. > > > On Thu, Oct 14, 2021 at 11:32 AM bened

Re: Tradeoffs for Cassandra transaction management

> valuing community over code “Community” involves treating others with respect: following the norms of conversation by acknowledging and responding to the points and queries of others, accepting when you have a minority position, and stepping aside when your goals are not clearly in conflict

Re: Moving CEP-15 forward

Hi Jonathan, This clarifying change has been incorporated. If you both rescind your veto, we have time to rescue this vote. From: Jonathan Ellis Date: Friday, 15 October 2021 at 19:11 To: dev Subject: Moving CEP-15 forward Hi all, We have had several discussions today as to how to move

Re: [DISCUSS] CEP-17: Add support for PEM based key material for SSL

Hi Maulin, This sounds fine to me, though I don’t consider myself well versed in these system details. I have a meta comment though: I think this could easily have been a Jira with a DISCUSS thread brought to the list. The CEP process is (in my opinion) for complex decisions that needs broad

Re: [DISCUSS] CEP-15: General Purpose Transactions

n single-row reads and writes have to pay the full coordination > > cost. Fauna has optimized this away for reads but I am not aware of a > > description of how they changed the design to allow this. > > > > Functionality and limitations: since the entire transaction mu

Re: [VOTE] CEP-15: General Purpose Transactions

Purpose Transactions 1. +1(nb) 2. +1(nb) 3. +1(nb) > On Oct 17, 2021, at 5:19 AM, Gary Dusbabek wrote: > > +1 for all three. > >> On Thu, Oct 14, 2021 at 11:31 AM bened...@apache.org >> wrote: >> >> Hi everyone, >> >> I would like to start a

Re: [DISCUSS] CEP-15: General Purpose Transactions

lks lined up to implement > them. > > The CEP is a clear and meaningful improvement over status quo. The > engineers behind it are committed to doing the implementation work and can > be trusted to stick around for maintenance. It’s been a month now, please, > let’s get this g

Re: [DISCUSS] CASSANDRA-16922 CEP-10: Major Prerequisites (Phase 1)

able to me. Incremental work is always preferable, easier to > > maintain. > > > > > > On Fri, 17 Sep 2021 at 16:40, bened...@apache.org > > wrote: > > > >> It’s worth clarifying that CEP-10 has been broken up into phases, and > >> this w

Re: [DISCUSS] CASSANDRA-16922 CEP-10: Major Prerequisites (Phase 1)

changed in the meanwhile. Regards On Tue, 28 Sept 2021 at 14:06, bened...@apache.org wrote: > > Hi everyone, > > Just wanted to send out a final call before I start merging Phase 1 of > CEP-10. If somebody is keen to get involved pipe up here - more than happy to > def

Re: [DISCUSS] CEP-15: General Purpose Transactions

021, at 6:18 PM, Jonathan Ellis wrote: > > How are interactive transactions possible with Accord? > > > > On Tue, Sep 21, 2021 at 11:56 PM bened...@apache.org > wrote: > >> Could you explain why you believe this trade-off is necessary? We can >> support ful

Re: [DISCUSS] CEP-15: General Purpose Transactions

of features that will be enabled by Accord and using that as the initial CEP to introduce the protocol to the database? Em sex., 1 de out. de 2021 às 08:37, bened...@apache.org < bened...@apache.org> escreveu: > Actually, thinking about it again, the simple optimistic protocol would

Re: [DISCUSS] CEP-15: General Purpose Transactions

added by previous CEP. - High-level architecture: blablabla... and so on. Em sex., 1 de out. de 2021 às 10:19, bened...@apache.org < bened...@apache.org> escreveu: > I think this is getting circular and unproductive. Basic disagreements > about whether the CEP specifies a feature I am

Re: [DISCUSS] CEP-15: General Purpose Transactions

there is a similar optimization for Accord where transactions from the same coordinator can be allowed to commit within the SkewMax window, because we can assume that the trx timestamps originating at the same coordinator cannot arrive out of order when using TPC? henrik On Mon, Sep 27,

Re: [DISCUSS] CEP-15: General Purpose Transactions

ume from an external point of view, and this seems like an appropriate and contextualized place to voice this opinion which is perhaps shared by others. Em sex., 1 de out. de 2021 às 10:55, bened...@apache.org < bened...@apache.org> escreveu: > I disagree with you. However, this is the

Re: [DISCUSS] CEP-15: General Purpose Transactions

sex., 1 de out. de 2021 às 11:10, bened...@apache.org < bened...@apache.org> escreveu: > I’m not, though it might seem that way. I disagree with your views about > how CEP should be structured. Since the CEP process was itself codified via > the CEP process, if you want to rec

Re: [DISCUSS] CEP-15: General Purpose Transactions

that it may be engaged with on the same terms. From: bened...@apache.org Date: Friday, 1 October 2021 at 14:19 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions I think this is getting circular and unproductive. Basic disagreements about whether the CEP

Re: [DISCUSS] CEP-15: General Purpose Transactions

ploratory process with respect to structure, and these decisions will be made as the CEP progresses. If these need to be specified upfront, then the purpose of a CEP – seeking buy in – is invalidated, because the work must be complete before you know the answers. From: bened...@apache.org Date:

Re: [DISCUSS] CEP-15: General Purpose Transactions

me it's much easier to visualize a project top-down (from how it's going to be used to its particular implementation details) versus the other way around. Em sex., 1 de out. de 2021 às 11:33, bened...@apache.org < bened...@apache.org> escreveu: > > The current document details thorough

Re: [DISCUSS] CEP-15: General Purpose Transactions

– do you have any technical papers to hand? From: Henrik Ingo Date: Friday, 1 October 2021 at 16:24 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions On Fri, Oct 1, 2021 at 5:30 PM bened...@apache.org wrote: > > Typical value for SkewMax in e.g.

Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection

iche consistency levels to the default CL table which may create confusion to non-power users. Em qua., 6 de out. de 2021 às 10:12, bened...@apache.org < bened...@apache.org> escreveu: > Hi Everyone, > > This is a modest user-facing feature that I want to highlight in case &

[DISCUSS] CASSANDRA-17024: Artificial Latency Injection

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

Re: [DISCUSS] CEP-15: General Purpose Transactions

not simply to bless a completed design. That's why we're going in circles here. On Wed, Oct 6, 2021 at 2:12 AM bened...@apache.org wrote: > 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

Re: [DISCUSS] CEP-15: General Purpose Transactions

Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions 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. Th

Re: [DISCUSS] CEP-15: General Purpose Transactions

cile the ’new ballot has been issued’ language with the ‘any R in responses had X as Applied, Committed, or Accepted’ language. Well done again and thank you for pushing the envelope in this area Benedict. Miles > On 15 Sep 2021, at 11:33 pm, bened...@apache.org wrote: > >>

Re: [DISCUSS] CEP-15: General Purpose Transactions

can be expressed with the > > current syntax that we refuse now and would be able to accept with this, so > > those could be "ground zero" of what this work would allow. > > > > But outside of pure syntax questions, one thing that I don't see discussed > > in

Re: [DISCUSS] CEP-15: General Purpose Transactions

. Instead of right after your talk Benedict, maybe we can set a time for next week and let everyone know the time? Patrick On Mon, Sep 20, 2021 at 11:05 AM bened...@apache.org wrote: > Hi Joey, > > Thanks for the feedback and suggestions. > > > I was wondering what do you think

Re: [DISCUSS] CEP-15: General Purpose Transactions

FWIW I retract this – looking again at the blog post I don’t see adequate reason to infer they are using a leaderless approach. On balance I expect Fauna is still using a stable leader. Do you have reason to believe they are now leaderless? From: bened...@apache.org Date: Wednesday, 22

  1   2   3   >