Re: CEP-15 multi key transaction syntax

Yeah, if you remember Blake's original syntax proposal, the IF condition was actually specified outside the body of the transaction following the COMMIT TRANSACTION phrase. (i.e. COMMIT TRANSACTION IF blah, blah) The current syntax only changed that superficially, but in doing so, it left the

Re: CEP-15 multi key transaction syntax

> I expect that a lot of use cases will update M and insert into N tables based > on one condition Jeff, the issue is a scope issue — works fine today IF … UPDATE ….; INSERT …; END IF — also works today just fine; no condition is used with the mutations UPDATE ….; INSERT …; — does not

Re: CEP-15 multi key transaction syntax

Not quite sure I follow, but the syntax we agreed permits you to update as many tables as you like with a single condition, or with no condition, but not to mix both conditional and unconditional updates in a single transaction. My preference is to keep this simple until we permit arbitrarily

Re: CEP-15 multi key transaction syntax

I expect that a lot of use cases will update M and insert into N tables based on one condition, so if that's a problem with the grammar today, I think it'd probably be worth the time to sort that out? On Wed, Sep 21, 2022 at 12:42 PM David Capwell wrote: > Caleb is making great progress on

Re: CEP-15 multi key transaction syntax

My inclination is not to support this until we support arbitrary numbers of IF statements. It’s one too many arbitrary restrictions and it potentially gets confusing. But I don’t feel super strongly about it. > On 21 Sep 2022, at 20:56, Patrick McFadin wrote: > >  > I'm also working on

Re: CEP-15 multi key transaction syntax

I'm also working on different use cases and syntax for Accord :D I'm +1 on this change and leaving the door open for maybe a few more as we test this out. It needs to be functionally useful for developers in v1, and I think it's worth the changes to get it right. One other thing Caleb and I have

Re: CEP-15 multi key transaction syntax

Caleb is making great progress on this, and I have been working on CQL fuzz testing the new grammar to make sure we flesh out cases quickly; one thing we hit was about mixing conditional and non-conditional updates; will use a example to better show BEGIN TRANSACTION LET a = (SELECT * FROM

Re: CEP-15 multi key transaction syntax

I wasn't referring to specific syntax but to the concept. If a SQL dialect (or better, the standard) has a way to select data into a variable, let's adopt it. If such syntax doesn't exist, LET (a, b, c) = (SELECT x, y, z FROM tab) is my preference. On 8/22/22 19:13, Patrick McFadin wrote:

Re: CEP-15 multi key transaction syntax

The replies got trashed pretty badly in the responses. When you say: "Agree it's better to reuse existing syntax than invent new syntax." Which syntax are you referring to? Patrick On Mon, Aug 22, 2022 at 1:36 AM Avi Kivity via dev wrote: > Agree it's better to reuse existing syntax than

Re: CEP-15 multi key transaction syntax

Agree it's better to reuse existing syntax than invent new syntax. On 8/21/22 16:52, Konstantin Osipov wrote: * Avi Kivity via dev [22/08/14 15:59]: MySQL supports SELECT INTO FROM ... WHERE ... PostgreSQL supports pretty much the same syntax. Maybe instead of LET use the

Re: CEP-15 multi key transaction syntax

> On 21 Aug 2022, at 14:59, Benedict wrote: > > SELECT INTO in T-SQL creates a new table with the results. Since our > semantics are likely to be different than Postgres and MySQL, I’m not sure > it’s less confusing or otherwise beneficial to mimic an existing syntax. > > Personally I

Re: CEP-15 multi key transaction syntax

Just updated the Jira to reflect the latest conversation here. On Mon, Aug 15, 2022 at 1:06 PM Patrick McFadin wrote: > I am +1 on > > IS NOT NULL/IS NULL instead of EXISTS/NOT EXISTS > > Not requiring (but allowing) SELECT on LET > >

Re: CEP-15 multi key transaction syntax

Ha, apologies to Avi ;) On Mon, Aug 15, 2022 at 2:01 PM Benedict Elliott Smith wrote: >  > > I like Benedict's tuple deconstruction idea > > > For posterity, this was Avi’s idea! > > On 15 Aug 2022, at 18:59, Caleb Rackliffe > wrote: > > Monday Morning Caleb has digested, and here's where I

Re: CEP-15 multi key transaction syntax

 > I like Benedict's tuple deconstruction idea For posterity, this was Avi’s idea! > On 15 Aug 2022, at 18:59, Caleb Rackliffe wrote: > > Monday Morning Caleb has digested, and here's where I am... > > 1.) I have no problem w/ having SELECT on the RHS of a LET assignment, and to > be

Re: CEP-15 multi key transaction syntax

I am +1 on IS NOT NULL/IS NULL instead of EXISTS/NOT EXISTS Not requiring (but allowing) SELECT on LET Patrick On Mon, Aug 15, 2022 at 11:01 AM Caleb Rackliffe wrote: > Monday Morning Caleb has digested, and here's where I am... > > 1.) I have no problem w/ having SELECT on the RHS of a LET

Re: CEP-15 multi key transaction syntax

Monday Morning Caleb has digested, and here's where I am... 1.) I have no problem w/ having SELECT on the RHS of a LET assignment, and to be honest, this may make some implementation things easier for me (i.e. the encapsulation of SELECT within LET) 2.) I'm in favor of LET without a select,

Re: CEP-15 multi key transaction syntax

  > > Verbose version: > LET (a) = SELECT val FROM table > IF a > 1 THEN... > > Less verbose version: > LET a = SELECT val FROM table > IF a.val > 1 THEN... My intention is that these are actually two different ways of expressing the same thing, both supported and neither intended to be

Re: CEP-15 multi key transaction syntax

Let me just state my bias right up front. For any kind of QL I lean heavily toward verbose and explicit based on their lifecycle. A CQL query will probably need to be understood by the next person looking at it, and a few seconds saved typing isn't worth the potential misunderstanding later. My

Re: CEP-15 multi key transaction syntax

 > > I think SQL dialects require subqueries to be parenthesized (not sure). If > that's the case I think we should keep the tradition. > This isn’t a sub-query though, since LET is not a query. If we permit at most one SELECT, and do not permit mixing SELECT with constant assignments, I

Re: CEP-15 multi key transaction syntax

On 14/08/2022 17.50, Benedict Elliott Smith wrote:  > SELECT and LET incompatible once comparisons become valid selectors I don’t think this would be ambiguous, as = is required in the LET syntax as we have to bind the result to a variable name. But, I like the deconstructed tuple syntax

Re: CEP-15 multi key transaction syntax

 > SELECT and LET incompatible once comparisons become valid selectors I don’t think this would be ambiguous, as = is required in the LET syntax as we have to bind the result to a variable name. But, I like the deconstructed tuple syntax improvement over “Option 6”. This would also seem to

Re: CEP-15 multi key transaction syntax

On 14/08/2022 01.29, Benedict Elliott Smith wrote:  I’ll do my best to express with my thinking, as well as how I would explain the feature to a user. My mental model for LET statements is that they are simply SELECT statements where the columns that are selected become variables

Re: CEP-15 multi key transaction syntax

 I’ll do my best to express with my thinking, as well as how I would explain the feature to a user. My mental model for LET statements is that they are simply SELECT statements where the columns that are selected become variables accessible anywhere in the scope of the transaction. That is to

Re: CEP-15 multi key transaction syntax

I'm really happy to see CEP-15 getting closer to a final implementation. I'm going to walk through my reasoning for your proposals wrt trying to explain this to somebody new. Looking at all the options, the first thing that comes up for me is the Cassandra project's complicated relationship with

Re: CEP-15 multi key transaction syntax

...and one more option... 5.) Introduce tuple assignments, removing all ambiguity around row vs. column operations. BEGIN TRANSACTION LET row1 = * FROM ks.tbl WHERE k=0 AND c=0; <-- * selects all columns LET row2 = (v) FROM ks.tbl WHERE k=1 AND c=0; SELECT row1.v, row2.v IF row1 IS NULL

Re: CEP-15 multi key transaction syntax

via Benedict, here is a 4th option: 4.) Similar to #2, but don't rely on the key element being NULL. If the read returns no result, x effectively becomes NULL. Otherwise, it remains true/NOT NULL. BEGIN TRANSACTION LET x = true FROM ks.tbl WHERE k=0 AND c=0; LET row2_v = v FROM ks.tbl WHERE

Re: CEP-15 multi key transaction syntax

Hello again everyone! I've been working on a prototype in CASSANDRA-17719 for a grammar that roughly corresponds to what we've agreed on in this thread. One thing that isn't immediately obvious to me is how the LET syntax handles cases where

Re: CEP-15 multi key transaction syntax

Avi brought up an interesting point around NULLness checking in CASSANDRA-17762 ... In SQL, any comparison with NULL is NULL, which is interpreted as FALSE in > a condition. To test for NULLness, you use IS NULL or IS NOT NULL. But LWT > uses

Re: CEP-15 multi key transaction syntax

The new syntax looks great, and I’m really excited to see this coming together. One piece of feedback on the proposed syntax is around the use of “=“ as a declaration in addition to its current use as an equality operator in a WHERE clause and an assignment operator in an UPDATE: BEGIN

Re: CEP-15 multi key transaction syntax

I think we’ve converged on a starting syntax. Are there any additional comments before I open a JIRA? > On Jun 16, 2022, at 10:33 AM, Blake Eggleston wrote: > > I think in any scenario where the same cell is updated multiple times, the > last one would win. The final result for s3 in your

Re: CEP-15 multi key transaction syntax

I think in any scenario where the same cell is updated multiple times, the last one would win. The final result for s3 in your example would be 2 > On Jun 16, 2022, at 10:31 AM, Jon Meredith wrote: > > The reason I brought up static columns was for cases where multiple > statements update

Re: CEP-15 multi key transaction syntax

The reason I brought up static columns was for cases where multiple statements update them and there could be ambiguity. CREATE TABLE tbl { pk1 int, ck2 int, s3 static int, r4 static int, PRIMARY KEY (pk1, ck2) } BEGIN TRANSACTION UPDATE tbl SET s3=1, r4=1 WHERE pk1=1 AND ck2=1; UPDATE

Re: CEP-15 multi key transaction syntax

I like Postgres' approach of letting you declare an exceptional condition and failing if there is not precisely one result (though I would prefer to differentiate between 0 row->Null and 2 rows->first row), but once you permit coercing to NULL I think you have to then treat it like NULL and

Re: CEP-15 multi key transaction syntax

Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a little trickier. Assigning null to a column seems ok, but we should raise an exception if they're doing math or something that expects a non-null value > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith > wrote:

Re: CEP-15 multi key transaction syntax

AFAICT that standard addresses server-side cursors, not the assignment of a query result to a variable. Could you point to where it addresses variable assignment? Postgres has a similar concept, SELECT INTO[1], and it explicitly returns NULL if there are no result rows, unless STRICT is

Re: CEP-15 multi key transaction syntax

I see what you mean. We have the EXISTS/NOT EXISTS condition for explicitly checking for the existence of a row. One thing the old syntax did is how it handled references to columns that don't exist. Previously, if any column reference didn't resolve, the update wouldn't apply. With the new

Re: CEP-15 multi key transaction syntax

* bened...@apache.org [22/06/16 00:00]: > First some history: static rows are an efficiency sop to those > who migrated from the historical wide row world, where you could > have “global” partition state fetched with every query, and to > support the deprecation of thrift and its horrible data

Re: CEP-15 multi key transaction syntax

* bened...@apache.org [22/06/13 17:37]: > I believe that is a MySQL specific concept. This is one problem with > mimicking SQL – it’s not one thing! > > In T-SQL, a Boolean expression is TRUE, FALSE or UNKNOWN[1], and a NULL value > submitted to a Boolean operator yields UNKNOWN. > > IF (X)

Re: CEP-15 multi key transaction syntax

e? From: Konstantin Osipov Date: Wednesday, 15 June 2022 at 20:56 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax * bened...@apache.org [22/06/15 18:38]: > I expect LET to behave like SELECT, and I don’t expect this work to modify > the behaviour of normal

Re: CEP-15 multi key transaction syntax

* bened...@apache.org [22/06/15 18:38]: > I expect LET to behave like SELECT, and I don’t expect this work to modify > the behaviour of normal CQL expressions. Do you think there is something > wrong or inconsistent about the behaviours you mention? > > Static columns are a bit weird, but at

Re: CEP-15 multi key transaction syntax

Osipov Date: Wednesday, 15 June 2022 at 14:04 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax * bened...@apache.org [22/06/15 10:00]: > It sounds like we’re zeroing in on a solution. > > To draw attention back to Jon’s email, I think the last open

Re: CEP-15 multi key transaction syntax

* bened...@apache.org [22/06/15 10:00]: > 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. > >

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<mailto:be

Re: CEP-15 multi key transaction syntax

SET miles_driven = user_miles + 30 WHERE name='blake'; > UPDATE cars SET miles_driven = car_miles + 30 WHERE model='pinto'; > > END IF > > COMMIT TRANSACTION > > > > > > > > *From: *Derek Chen-Becker > *Date: *Tuesday, 14 June 2022 at 21:27 > *To: *dev@cassandra.a

Re: CEP-15 multi key transaction syntax

em, e.g. > > > > > Any other ideas? > > > > > > > > *From: *Derek Chen-Becker > *Date: *Tuesday, 14 June 2022 at 20:31 > *To: *dev@cassandra.apache.org > *Subject: *Re: CEP-15 multi key transaction syntax > > Sorry, that was in reference to the

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

Re: CEP-15 multi key transaction syntax

for all input parameters to an assignment in UPDATE 2. Add some additional syntax to local variables to identify them, e.g. Any other ideas? From: Derek Chen-Becker Date: Tuesday, 14 June 2022 at 20:31 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax Sorry

Re: CEP-15 multi key transaction syntax

o apply (must include > partition key), plus (initially) no range scans, and the aforementioned > restrictions on what order statements must occur in the transaction. > > > > > > *From: *Derek Chen-Becker > *Date: *Tuesday, 14 June 2022 at 18:42 > *To: *dev@cassand

Re: CEP-15 multi key transaction syntax

interactive transactions, or JOINs, or anything else we might add in future. From: Derek Chen-Becker mailto:de...@chen-becker.org>> Date: Monday, 13 June 2022 at 23:09 To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org> mailto:dev@cassandra.apache.org>> Subject: Re: C

Re: CEP-15 multi key transaction syntax

actions, or JOINs, or anything else we > might add in future. > > > > > > *From: *Derek Chen-Becker > *Date: *Monday, 13 June 2022 at 23:09 > *To: *dev@cassandra.apache.org > *Subject: *Re: CEP-15 multi key transaction syntax > > On Mon, Jun 13, 2022 at 1:5

Re: CEP-15 multi key transaction syntax

END IF 3) The AS syntax – do we want this to look more like SQL, i.e. SELECT X FROM tbl AS mytableref? From: Blake Eggleston Date: Tuesday, 14 June 2022 at 00:33 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax > It’s something to hammer out in more detail once

Re: CEP-15 multi key transaction syntax

otherval=12 WHERE key=10; END COMMIT TRANSACTION It would be quite easy to relax this (maybe even before release), but it gets us off the starting block without planned obsolescence. From: Blake Eggleston Date: Monday, 13 June 2022 at 23:57 To: dev@cassandra.apache.org Subject: Re: CEP-15 mult

Re: CEP-15 multi key transaction syntax

bly do that, introduce new keywords that look and feel like SQL but aren’t, so there is no confusion From: Derek Chen-Becker Date: Monday, 13 June 2022 at 23:07 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax I'm coming to this thread fresh and admittedly I'm still trying to

Re: CEP-15 multi key transaction syntax

* offer interactive transactions, or JOINs, or anything else we might add in future. From: Derek Chen-Becker Date: Monday, 13 June 2022 at 23:09 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax On Mon, Jun 13, 2022 at 1:57 PM Blake Eggleston mailto:beggles

Re: CEP-15 multi key transaction syntax

n the face of >> coordinator failure (so the transaction id is unknown to the client). The >> more complete approach is for the client to include an idempotency token in >> its submission to the server, and for C* to record this alongside the >> transaction id, and for some bo

Re: CEP-15 multi key transaction syntax

ermit us to remove one result set (the success/failure > one) and return instead an exception if the transaction is aborted. This is > also more consistent with SQL, if memory serves. That might conflict with > returning the other result sets in the event of abort (though that’s up to > us ultimately),

Re: CEP-15 multi key transaction syntax

ily. But if we settle what our preferred syntax is, we can see if there’s time to deliver it before a release. Either way, the syntax evolves on a consistent path. From: Blake Eggleston Date: Monday, 13 June 2022 at 20:57 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax R

Re: CEP-15 multi key transaction syntax

ransaction id is unknown to the client). The more complete approach is >> for the client to include an idempotency token in its submission to the >> server, and for C* to record this alongside the transaction id, and for some >> bounded time window to either reject re-submissions of this to

Re: CEP-15 multi key transaction syntax

me bounded > time window to either reject re-submissions of this token or to evaluate it > as a no-op. This requires much tighter integration from the clients, and more > work server-side. > > > > Which is simply to say, this is on our radar but I can’t make promises about

Re: CEP-15 multi key transaction syntax

r some bounded time window to either reject > re-submissions of this token or to evaluate it as a no-op. This requires > much tighter integration from the clients, and more work server-side. > > > > Which is simply to say, this is on our radar but I can’t make promises > about what form

Re: CEP-15 multi key transaction syntax

, 13 June 2022 at 14:57 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax > IF (X) THEN > ROLLBACK > RETURN (ERRCODE) > END IF > > or > > IF (X) THEN RAISERROR > > So, that is in essence the question we are currently asking: do >

Re: CEP-15 multi key transaction syntax

> IF (X) THEN > ROLLBACK > RETURN (ERRCODE) > END IF > > or > > IF (X) THEN RAISERROR > > So, that is in essence the question we are currently asking: do > we want to have a more LWT-like approach (and if so, how do we > address this complexity for the user), or do we want a more >

Re: CEP-15 multi key transaction syntax

adar but I can’t make promises about what form it will take, or when it will arrive, only that it has been planned for enough to ensure we can achieve it when resources permit. From: Li Boxuan Date: Sunday, 12 June 2022 at 16:14 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transact

Re: CEP-15 multi key transaction syntax

:pmcfa...@gmail.com>> Date: Saturday, 11 June 2022 at 15:33 To: dev mailto:dev@cassandra.apache.org>> Subject: Re: CEP-15 multi key transaction syntax I think the syntax is evolving into something pretty complicated, which may be warranted but I wanted to take a step back and be a

Re: CEP-15 multi key transaction syntax

..@gmail.com>> Date: Saturday, 11 June 2022 at 15:33 To: dev mailto:dev@cassandra.apache.org>> Subject: Re: CEP-15 multi key transaction syntax I think the syntax is evolving into something pretty complicated, which may be warranted but I wanted to take a step back and be a bit more re

Re: CEP-15 multi key transaction syntax

ant here as people execute more complex transactions, and we should ideally have semantics that will work well into the future – including if we later introduce interactive transactions. From: Patrick McFadin Date: Saturday, 11 June 2022 at 15:33 To: dev Subject: Re: CEP-15 multi key tr

Re: CEP-15 multi key transaction syntax

it feels like a nicer API for the user – depending on > how these exceptions are surfaced in client APIs. > > > > *From: *bened...@apache.org > *Date: *Friday, 10 June 2022 at 19:59 > *To: *dev@cassandra.apache.org > *Subject: *Re: CEP-15 multi key transaction syntax > >

Re: CEP-15 multi key transaction syntax

to us ultimately), but it feels like a nicer API for the user – depending on how these exceptions are surfaced in client APIs. From: bened...@apache.org Date: Friday, 10 June 2022 at 19:59 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax So, thinking on it myself

Re: CEP-15 multi key transaction syntax

@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax Yeah I think that’s intuitive enough. I had been thinking about multiple condition branches, but was thinking about something closer to IF select.column=5 UPDATE ... SET ... WHERE key=1; ELSE IF select.column=6 UPDATE ... SET

Re: CEP-15 multi key transaction syntax

n look very much like SQL. > > > From: Blake Eggleston > Date: Wednesday, 8 June 2022 at 20:59 > To: dev@cassandra.apache.org > Subject: Re: CEP-15 multi key transaction syntax > > > It affects not just RETURNING but also conditions that are evaluated > > again

Re: CEP-15 multi key transaction syntax

: Wednesday, 8 June 2022 at 20:59 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax > It affects not just RETURNING but also conditions that are evaluated against > the row, and if we in future permit using the values from one select in a > function call / write t

Re: CEP-15 multi key transaction syntax

> > > > From: Blake Eggleston mailto:beggles...@apple.com>> > Date: Monday, 6 June 2022 at 23:17 > To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> > mailto:dev@cassandra.apache.org>> > Subject: Re: CEP-15 multi key transaction syntax > &g

Re: CEP-15 multi key transaction syntax

process the execution. Most transactions won’t need it, I suspect, so we don’t need to worry about perfect efficiency. From: Blake Eggleston Date: Tuesday, 7 June 2022 at 00:21 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax That's a good question. I'd lean

Re: CEP-15 multi key transaction syntax

think highly desirable for user experience, but this > does complicate it a bit if we want to remain intuitive. > > > > > From: Blake Eggleston > Date: Monday, 6 June 2022 at 23:17 > To: dev@cassandra.apache.org > Subject: Re: CEP-15 multi key transaction syntax > &

Re: CEP-15 multi key transaction syntax

values as of a given point in the sequential execution then? The succinct syntax is I think highly desirable for user experience, but this does complicate it a bit if we want to remain intuitive. From: Blake Eggleston Date: Monday, 6 June 2022 at 23:17 To: dev@cassandra.apache.org Subject: Re: CEP-15 mul

Re: CEP-15 multi key transaction syntax

Hi all, Thanks for all the input and questions so far. Glad people are excited about this! I didn’t have any free time to respond this weekend, although it looks like Benedict has responded to most of the questions so far, so if I don’t respond to a question you asked here, you can interpret

Re: CEP-15 multi key transaction syntax

On Mon, Jun 6, 2022 at 5:28 PM bened...@apache.org wrote: > > One way to make it obvious is to require the user to explicitly type > the SELECTs and then to require that all SELECTs appear before > UPDATE/INSERT/DELETE. > > > > Yes, I agree that SELECT statements should be required to go first.

Re: CEP-15 multi key transaction syntax

it’s fine to require a client upgrade to get multiple result sets. From: Henrik Ingo Date: Monday, 6 June 2022 at 15:18 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax Thank you Blake and team! Just some personal reactions and thoughts... First instinct is to s

Re: CEP-15 multi key transaction syntax

Thank you Blake and team! Just some personal reactions and thoughts... First instinct is to support the shorter format where UPDATE ... AS car is also its own implicit select. However, a subtle thing to note is that a reasonable user might expect that in a sequence of multiple UPDATEs, each of

Re: CEP-15 multi key transaction syntax

clared in a single statement. I think Accord can be extended to natively support interactive transactions in future, in a manner consistent with its fast non-interactive transactions, but that’s a whole other endeavour. From: Patrick McFadin Date: Sunday, 5 June 2022 at 01:47 To: dev Subject: R

Re: CEP-15 multi key transaction syntax

Miller Date: Sunday, 5 June 2022 at 03:39 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax All of my text below largely extends your question of syntax in a few directions: - What is the user experience of trying to run different statements with this syntax? - How

Re: CEP-15 multi key transaction syntax

Love the Oracle/Postgres RETURNING syntax and just generally +1 to adding INSERT and DELETE. And for each DML type... > - INSERT ... RETURNING returns inserted data (useful for defaulted or > autoincrement columns). > - UPDATE ... RETURNING returns the modified data. > - DELETE ... RETURNING

Re: CEP-15 multi key transaction syntax

All of my text below largely extends your question of syntax in a few directions: - What is the user experience of trying to run different statements with this syntax? - How do transactions interact with other Cassandra constructs? - What are the execution semantics of these statements? which I

Re: CEP-15 multi key transaction syntax

modification statements, but commit if 1=1 ? >> >> >> >> My preference is that the IF condition is anyway optional, as it is much >> more obvious to a user than concocting some always-true condition. But yes, >> read-only transactions involving multi

Re: CEP-15 multi key transaction syntax

cocting some always-true condition. But yes, > read-only transactions involving multiple tables will definitely be > supported. > > > > > > *From: *Jeff Jirsa > *Date: *Saturday, 4 June 2022 at 22:49 > *To: *dev@cassandra.apache.org > *Subject: *Re: CEP-15 mult

Re: CEP-15 multi key transaction syntax

: Jeff Jirsa Date: Saturday, 4 June 2022 at 22:49 To: dev@cassandra.apache.org Subject: Re: CEP-15 multi key transaction syntax And would you allow a transaction that had > 1 named select and no modification statements, but commit if 1=1 ? > On Jun 4, 2022, at 2:45 PM, Jeff Jirsa wrote: &

Re: CEP-15 multi key transaction syntax

And would you allow a transaction that had > 1 named select and no modification statements, but commit if 1=1 ? > On Jun 4, 2022, at 2:45 PM, Jeff Jirsa wrote: > >  > >> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote: >> >> Hi dev@, > > First, I’m ridiculously excited to see this.

Re: CEP-15 multi key transaction syntax

> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote: > > Hi dev@, First, I’m ridiculously excited to see this. > > I’ve been working on a draft syntax for Accord transactions and wanted to > bring what I have to the dev list to solicit feedback and build consensus > before moving

CEP-15 multi key transaction syntax

Hi dev@, I’ve been working on a draft syntax for Accord transactions and wanted to bring what I have to the dev list to solicit feedback and build consensus before moving forward with it. The proposed transaction syntax is intended to be an extended batch syntax. Basically batches with