[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Epic Link: CASSANDRA-17092
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
> Time Spent: 12.5h
> Remaining Estimate: 0h
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating read commands and mutations until later in the transaction
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Source Control Link:
https://github.com/apache/cassandra/commit/33f670bab67643b4ac0220e4be99c23b3104080e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed to {{cep-15-accord}} branch.
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Status: Ready to Commit (was: Review In Progress)
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating read commands and mutations
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Reviewers: Ariel Weisberg, David Capwell (was: Blake Eggleston, David
Capwell)
Status: Review In Progress (was: Patch Available)
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
> Time Spent: 11h 50m
> Remaining Estimate: 0h
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Authors: Blake Eggleston, Caleb Rackliffe, David Capwell (was: Caleb
Rackliffe)
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
> Time Spent: 11h 50m
> Remaining Estimate: 0h
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Test and Documentation Plan: new in-JVM/unit testing around CQL-based
transaction validation and execution
Status: Patch Available (was: In Progress)
|[patch (based on
{{cep-15-accord}})|https://github.com/apache/cassandra/pull/1962]|[CircleCi
J8|https://app.circleci.com/pipelines/github/maedhroz/cassandra/641/workflows/1d4420f3-232e-4df5-ac74-478b33e0ceae]|[Circle
CI
j11|https://app.circleci.com/pipelines/github/maedhroz/cassandra/641/workflows/68129722-7fd0-44a6-a2f4-5e58473eec0f]|
...and here we are. A brief summary of what I'm seeing in the test results
would probably be helpful for whoever reviews:
*Tests that are failing, but also failing in {{cep-15-accord}}*
- {{AsyncWriterTest}} ({{commandsPerKeyDenormalization}},
{{waitinOnDenomalization}}, partialCommandDenomalization)
- {{PaxosRepairHistoryTest}} ({{testRandomTrims}}, {{testRandomAdds}})
- {{AccordIntegrationTest.multipleShards}} (although the failures are different)
- {{read_repair_test.TestSpeculativeReadRepair.test_normal_read_repair}}
- {{read_repair_test.TestReadRepairGuarantees.test_atomic_writes}} &
{{test_monotonic_reads}}
-
{{upgrade_tests.bootstrap_upgrade_test.TestBootstrapUpgrade.test_resumable_bootstrap}}
- Tons of cqlsh dtests (ex. {{TestCqlsh.test_default_keyspaces_exist}})
- {{AccordCommandStoreTest}} ({{commandLoadSave}} and
{{commandsForKeyLoadSave}})
- {{AsyncLoaderTest}} ({{loadTest}} and {{pendingWriteOnlyApplied}})
- {{AsyncOperationTest.testFutureCleanup}}
- {{ShortAccordSimulationTest}} (reduce number of threads and it passes or at
least fails like upstream does)
*Test failures that only seem to time out on CircleCI and can’t be repro’d
locally in either branch (even w/ multiple runs, but stopped short of using the
multiplexer)
*
- {{SecondaryIndexTest.testCanQuerySecondaryIndex}}
- {{OfflineTokenAllocatorGenerationsTest.testTokenGenerations}}
- {{ViewFiltering1Test.testFilterWithFunction}}[3]
- {{ViewFilteringClustering1Test.testClusteringKeySliceRestrictions}}[3]
- {{RepairTest.testForcedNormalRepairWithOneNodeDown}}
- {{ReadFailureTest.testSpecExecRace}}
- {{CasCriticalSectiontest.criticalSectionTest}}
- {{MigrationCoordinatorTest}} ({{explicitVersionIgnore}} and
{{explicitEndpointIgnore}})
- {{InsertUpdateifConditionCollectionsTest.testInsertSetIfNotExists}}
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Fix Version/s: NA
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating read commands and mutations until later in the transaction process,
> and potentially on another machine, which means we
[jira] [Updated] (CASSANDRA-17719) CEP-15: Multi-Partition Transaction CQL Support (Alpha)
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Summary: CEP-15: Multi-Partition Transaction CQL Support (Alpha) (was:
CEP-15: Multi-Partition Transaction CQL Support v0.1)
> CEP-15: Multi-Partition Transaction CQL Support (Alpha)
> ---
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating read commands and mutations until later
