Re: Cassandra project biweekly status update 2022-06-14

There are 3 view filtering test failures in the 8 4.1 failures which are known offenders as being parametrized they might take long in an overloaded systems. Once we're back to normal capacity on jenkins they should be ok, finger in the air estimate, so we might be even better than 8. #collabor

Re: CEP-15 multi key transaction syntax

+1 From: Blake Eggleston Date: Tuesday, 14 June 2022 at 21:46 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax I'd lean towards 3, where the statement doesn't parse because `miles` is ambiguous On Jun 14, 2022, at 1:40 PM, bened...@apache.org

Re: CEP-15 multi key transaction syntax

OK, that makes sense. One of the examples in an earlier email had duplicate "LET miles =" so I was confused. I think failing in the face of ambiguous identifiers is going to be more friendly by not requiring LET for every field you might want to use, and we can provide a very clear error message in

Re: CEP-15 multi key transaction syntax

Just to make sure I'm understanding correctly, I've been thinking of LET like a variable declaration and assignment, but is that the right mental model? For example, this is a valid statement: BEGIN TRANSACTION LET miles = miles_driven, running=is_running FROM cars WHERE model=’pinto’ SELECT

Re: CEP-15 multi key transaction syntax

(or 3. Let schema updates break the statement – this might actually be preferable, so long as it fails-fast rather than corrupts behaviour) From: bened...@apache.org Date: Tuesday, 14 June 2022 at 20:58 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax It sounds like

Re: CEP-15 multi key transaction syntax

It sounds like we’re zeroing in on a solution. To draw attention back to Jon’s email, I think the last open question at this point is the scope of identifiers declared by LET, and how we handle name clashes with table columns in an UPDATE. I think we have basically two options: 1. Require LET

Re: CEP-15 multi key transaction syntax

Sorry, that was in reference to the "Would you require a LIMIT 1 clause if the key did not fully specify a row?" question, so I think we're in agreement here. Cheers, Derek On Tue, Jun 14, 2022 at 1:27 PM bened...@apache.org wrote: > > It seems like we would want to start with restrictions on

Re: CEP-15 multi key transaction syntax

> It seems like we would want to start with restrictions on number of rows, > uniqueness, homogeneity of results, etc I am not keen on any hard limit on the number of rows, I anticipate a configurable guardrail for rejecting queries that are too expensive. I think the normal CQL restrictions ar

Re: CEP-15 multi key transaction syntax

"MIXED" means, "hey, this might not be my standard PGSQL transaction" :) I do think that surprise is a meaningful measure, from the perspective of an individual developer coming to Cassandra from any arbitrary RDBMS. My own experience is that a non-trivial number of developers are essentially blin

Cassandra project biweekly status update 2022-06-14

How has it been two weeks already? 4.1 is high priority, so let's start there: https://butler.cassandra.apache.org/#/ Last run had 8 failed tests! We've had a pretty painful run in terms of CI infrastructure over the past week on 4.1 (see here: https://ci-cassandra.apache.org/job/Cassandra-4.1/

Re: CEP-15 multi key transaction syntax

> I … couldn't find an implementation that wasn't vendor specific. I’ve fallen into the same trap as others. You’re right, all control flow is vendor specific it turns out. So, we either need to consciously pick an SQL dialect to mimic (probably the safest would be pgsql), or make sure we are d