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 r
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
Oops. I missed this part: "full primary key or a limit of 1"
Still curious what the end-user would see if there is more than one row
returned.
On Sat, Jun 4, 2022 at 5:46 PM Patrick McFadin wrote:
> I've been waiting for this email! I'll echo what Jeff said about how
> exciting this is for the
I've been waiting for this email! I'll echo what Jeff said about how
exciting this is for the project.
On the SELECT inside the transaction:
In the first example, I'm making an assumption that you are doing a select
on a partition key and only expect one result but is any valid CQL SELECT
allowed
> The returned result set is after the updates are applied?
Returning the prior values is probably more powerful, as you can perform
unconditional updates and respond to the prior state, that you otherwise would
not know. It’s also simpler to implement.
My inclination is to require that SELECT
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.
> 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 forwar
sounds good. Lazy consensus it is.
> On Jun 4, 2022, at 11:09 AM, bened...@apache.org wrote:
>
>
> I think lazy consensus is good enough here, since there has been no dissent
> so far as I can tell. It’s easier to modify if we assume lazy consensus until
> a dispute arises. If anyone wants t
I think lazy consensus is good enough here, since there has been no dissent so
far as I can tell. It’s easier to modify if we assume lazy consensus until a
dispute arises. If anyone wants to escalate to a formal vote, feel free to say
so.
I’ll update the wiki in a couple of days; we can always
