[jira] [Commented] (CASSANDRA-18465) Add support for multiple condition branches and results in Accord transaction

["David Capwell (Jira)" <ji...@apache.org>]

    [ 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org