[ 
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642324#comment-17642324
 ] 

Caleb Rackliffe edited comment on CASSANDRA-17719 at 12/2/22 7:24 AM:
----------------------------------------------------------------------

|[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}}


was (Author: maedhroz):
|[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 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 <some conditions> THEN
>     <some update>;
>     <another update>;
>   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 <some conditions> THEN
>     <some update>;
>     <another update>;
>   ELSE IF <another condition> THEN
>     <yet another update>;
>   ELSE
>     <an update>;
>   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
> <value_reference> = 5
> <value_reference> 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 can't create accord 
> transactions with fully formed mutations and read commands. CQL statements 
> and terms are also not serializable, and would require a ton of work to 
> properly serialize, so there will need to be some intermediate stage that can 
> be serialized.



--
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

Reply via email to