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 combinat

[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 syst

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 Semb

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 roa

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 th

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 have

Re: Are we ready for 4.0.0 (GA) ?

> deploy changes from trunk into the releases they're deploying, as heavy > contributors doing so provides us the best opportunity to catch these > issues before our users do. > > > > We're getting close. > > > > >

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, > honestly

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 2

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: 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 Cassandra

Re: Additions to Cassandra ecosystem page?

park.apache.org/third-party-projects.html 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.

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: Be

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 unnece

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, or

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

> 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

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

-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: [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 W

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

torings, should only 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 consid

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

quality; and the risk of backports will increase, due to divergence. Altogether, I think it would be a huge mistake. But if we will be shipping releases soon that can fix these aforementioned regressions, I won’t campaign for it. From: bened...@apache.org Date: Tuesday, 13 July 2021 at 13:31 To

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

To: 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 w

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?&q

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 th

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 life

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

; we should create a minor version 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 >

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

> I think CEPs would benefit from describing their compatibility and stability impacts, rather than trying to tie themselves to a version, regardless of what context a specific version provides. Yes, we should perhaps remove target version from the template, and introduce guidance on describing s

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

-1 (binding) From: Dinesh Joshi Date: Saturday, 17 July 2021 at 05:38 To: dev@cassandra.apache.org Subject: Re: [VOTE] Release Apache Cassandra 4.0.0 (take2) Thanks for the heads up Jon. Please ping the list once you have filed the jira. Dinesh > On Jul 16, 2021, at 5:28 PM, Jon Meredith wrot

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

+1. I haven’t looked in detail at the API that’s been proposed, but I’m very much in favour of the work to support this, and the introduction of the newly proposed implementations. In particular, really happy to see somebody finally finish up C-7282! I look forward to seeing how the different a

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

rfaces, etc). Lots of quality work obviously went into this from a bunch of folks - thanks Branimir! ~Josh On Tue, Jul 20, 2021 at 6:20 AM bened...@apache.org wrote: > +1. I haven’t looked in detail at the API that’s been proposed, but I’m > very much in favour of the work to support

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

> memtable-as-a-commitlog-index Heh, based on 7282? Yeah, I’ve had this idea for a while now (actually there was a paper that did this a long time ago), and it could be very nice (if for no other benefit than reducing heap utilisation). I don’t think this requires that they be modelled as the s

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

I would love to help out with this in any way that I can, FYI. Definitely one of the more impactful performance improvements to the codebase, given the benefits to compaction and memory behaviour. From: bened...@apache.org Date: Wednesday, 21 July 2021 at 14:32 To: dev@cassandra.apache.org

[VOTE] CEP-10: Cluster and Code Simulations

Proposing the CEP-10 (Cluster and Code Simulations) for adoption Proposal: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10%3A+Cluster+and+Code+Simulations Discussion: https://lists.apache.org/thread.html/rc908165994b15a29ef9c17b0b1205b2abc5bd38228b5a0117e442104%40%3Cdev.cassandra.ap

[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] 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 Review

Re: [DISCUSS] Jira state for second reviewer

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] 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 > Review” a

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 t

[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 t

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 impleme

Re: [DISCUSS] CEP 14: Paxos Improvements

ussion Benedict :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 impl

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

fined 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 pm, bened.

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 to

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: Plug

[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 wil

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] 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 proposal

Re: [DISCUSS] CASSANDRA-15234

ggered Caleb and I to 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 t

[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-15: General Purpose Transactions

Otherwise 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+Purp

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

turned to the client? Even if you were proposing some Calvin-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 Su

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

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

ptember 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 a C

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: [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: > https://cw

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

est it before potentially 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

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

nd governance, and 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 p

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

ialize separately 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.or

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 CEP-1

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

g to reconcile 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: &g

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

can get pretty far on its own > > and could be a serious upfront distraction. > > > > And as you said, there are even queries that can be expressed with the > > current syntax that we refuse now and would be able to accept with this, so > > those could be "ground

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

l and LWT is almost certainly not sufficiently performant, so this would require ZK or etcd (reasonable for a library approach but not for replacing LWT in C* itself), or an implementation of Accord. I don’t believe Calvin would require additional table-level metadata in Cassandra. On Sun, Sep 5, 20

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

perhaps they are moving towards a similar approach. From: bened...@apache.org Date: Wednesday, 22 September 2021 at 03:52 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions Hi Jonathan, These other systems are incompatible with the goals of the CEP. I do

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

cheap serializable reads, and additionally is able to offer strict serializable reads without performing any write during consensus (nod to Alex Miller for pointing out this advantage over Calvin) From: bened...@apache.org Date: Wednesday, 22 September 2021 at 04:19 To: dev

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

strict serializability to get the ability to support full SQL. Both of these are nice to have! On Tue, Sep 21, 2021 at 9:52 PM bened...@apache.org wrote: > Hi Jonathan, > > These other systems are incompatible with the goals of the CEP. I do > discuss them (besides 2PC) in

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

call. 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

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

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

Ingo Date: Wednesday, 22 September 2021 at 15:15 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions On Wed, Sep 22, 2021 at 7:56 AM bened...@apache.org wrote: > Could you explain why you believe this trade-off is necessary? We can > support full SQL jus

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

. https://gather.town/app/2UKSboSjqKXIXliE/ac2021-cass-social From: bened...@apache.org Date: Wednesday, 22 September 2021 at 16:22 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions No, I would expect to deliver strict serializable interactive transactions

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

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

Ok, it’s time for the weekly poking of the hornet’s nest. Any more thoughts, questions or criticisms, anyone? From: bened...@apache.org Date: Friday, 24 September 2021 at 22:41 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions I’m not aware of anybody

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 will

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

x27;t 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 > d

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 full SQL

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

ms, get Item record, get/update Stock record 6. Insert Order-Line Record As you can see, this requires a lot of client-side logic mixed in with the actual SQL commands. On Thu, Sep 30, 2021 at 2:30 AM bened...@apache.org wrote: > Essentially this, although I think in practice we wil

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

Actually, thinking about it again, the simple optimistic protocol would in fact guarantee system forward progress (i.e. independent of transaction formulation). From: bened...@apache.org Date: Friday, 1 October 2021 at 09:14 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] CEP-15: General

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

ad 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 w

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

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

ded 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 inc

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

easier to consume 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,

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

g-sr.html#usr-hot-records>.) This makes me wonder whether 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 ou

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 recodify

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

t for 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 d

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

alera – 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

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

Hi everyone, It’s been a month since I brought this proposal forward. I think we’re ready for a vote, and I’d like to get a show of hands to see if others agree. I don’t intend for this to curtail any further questions or suggestions. I’m grateful for the continued healthy discussion, but from

Re: [VOTE] Release dtest-api 0.0.10

+1 From: Oleksandr Petrov Date: Tuesday, 5 October 2021 at 17:47 To: dev Subject: [VOTE] Release dtest-api 0.0.10 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 Cand

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

2021 at 9:34 AM bened...@apache.org wrote: > > The current document details thoroughly the protocol but in my view > lacks to illustrate what specific API, methods, modules will become > available to developers > > With respect to this, in my view this kind of detail is not w

[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 messages

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

s adding niche 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

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

arting in writing code, 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 trans

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

l table-level metadata in Cassandra. On Wed, Oct 6, 2021 at 9:53 AM bened...@apache.org wrote: > 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

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 your

  1   2   3   >