[
https://issues.apache.org/jira/browse/CASSANDRA-18465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18465:
------------------------------------------
Description:
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.
was:
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.
{{SELECT}}s 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. {{SELECT}}s 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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
