[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736256#comment-17736256
]
David Capwell commented on CASSANDRA-18465:
-------------------------------------------
left feedback in PR, but my main concern is the SELECT logic in the conditions
feels weird to me from a semantic point of view, so might be good to remove
that for now and only support update? If we do want the select, I feel we will
want to think through the semantics more
> Add support for multiple condition branches and results in Accord transaction
> -----------------------------------------------------------------------------
>
> Key: CASSANDRA-18465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18465
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
>
> I'd like to propose adding support for multiple branches and result sets for
> Accord transactions. It could look like this:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> LET c = ...
> IF condition THEN
> SELECT 1, a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 2, b.value
> UPDATE ...
> ELSE
> SELECT 3, c.value
> END IF
> COMMIT TRANSACTION
> {code}
> The existing syntax would remain valid, when a single SELECT is defined in
> which case the conditional SELECTs would not be valid.
> SELECTs would be validated to return columns of the same type. They would be
> able to return literals as well.
> This would be make the result of the transaction more intuitive as the client
> would know explicitly if the updates where applied or not.
> The following syntax would be considered as invalid:
> 1. SELECTs defined both on the top level and in branches
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> SELECT ... <--------------------------------
> IF condition THEN
> SELECT 'one', a.value <--------------------------------
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value <--------------------------------
> UPDATE ...
> ELSE
> SELECT 'three', NULL <--------------------------------
> END IF
> COMMIT TRANSACTION
> {code}
> 2. SELECT defined after update - select must be before the update to make it
> clear that the data is read before modification
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> UPDATE ...
> SELECT 'one', a.value <--------------------------------
> ELSE IF condition2 THEN
> UPDATE ...
> SELECT 'two', b.value
> ELSE
> SELECT 'three', NULL
> END IF
> COMMIT TRANSACTION
> {code}
> 3. Missing SELECT in a conditional branch - if SELECT is defined in a any
> conditional branch, it has to be defined in all branches:
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> ELSE IF condition2 THEN
> SELECT 'two', b.value
> UPDATE ...
> ELSE <--------------------------------
> UPDATE ...
> END IF
> COMMIT TRANSACTION
> {code}
> {code:sql}
> BEGIN TRANSACTION
> LET a = ...
> LET b = ...
> IF condition THEN
> SELECT 'one', a.value
> UPDATE ...
> END IF <-------------------------------- (else branch is implicit and it
> has no SELECT)
> COMMIT TRANSACTION
> {code}
> Selections in conditional branches will support only returning references -
> no support for full query is planned in this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
