[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573951#comment-17573951
]
Caleb Rackliffe commented on CASSANDRA-17719:
---------------------------------------------
Posting WIP
[here|https://github.com/maedhroz/cassandra/commits/CASSANDRA-17719-prototype].
Right now, I'm still reviewing Blake's prototype and slowly moving that syntax
to the new one (described above).
> CEP-15: (C*) Multi-partition transaction CQL support
> ----------------------------------------------------
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: 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_miles = miles_driven, car_is_running = is_running FROM cars WHERE
> model=’pinto’
> LET user_miles = miles_driven FROM users WHERE name=’blake’
> SELECT car_is_running, car_miles
> IF car_is_running THEN
> UPDATE users SET miles_driven = user_miles + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car_miles + 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_miles = miles_driven, car_is_running = is_running FROM cars WHERE
> model=’pinto’{code}
>
> The first part is basically a select statement where the front half assigns
> specific column values to a named reference that can be used in updates,
> conditions, or returned to the user. Reference names belong to a global scope
> and must not clash with value columns in 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}
>
> I haven't seen an example of an unconditional update (ie: not contained in an
> if block), but I don't see any reason not to support them. Though they don't
> need to be delivered in v1.
> h3. Conditions
> Comparisons of value references to literals or other references. EXISTS / NOT
> EXISTS 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: =, !=, >, >=, <, <=, EXISTS, NOT EXISTS
> <value_reference> = 5
> <value_reference> EXISTS
> IF car EXISTS AND miles_driven > 30
> IF miles_driven = miles_expected{code}
> 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
