diff --git a/modules/ROOT/pages/clauses/call-subquery.adoc b/modules/ROOT/pages/clauses/call-subquery.adoc index e95141e26..1df778181 100644 --- a/modules/ROOT/pages/clauses/call-subquery.adoc +++ b/modules/ROOT/pages/clauses/call-subquery.adoc @@ -415,11 +415,6 @@ RETURN p.name, youngerPersonsCount Subqueries can be made to execute in separate, inner transactions, producing intermediate commits. This can come in handy when doing large write operations, like batch updates, imports, and deletes. To execute a subquery in separate transactions, you add the modifier `IN TRANSACTIONS` after the subquery. -An outer transaction is opened to report back the accumulated statistics for the inner transactions -(created and deleted nodes, relationships, etc) and it will succeed or fail depending on the results -of those inner transactions. -For more information, see <>. -Canceling that outer transaction will cancel the inner ones. The following example uses a CSV file and the `LOAD CSV` clause to import more data to the example graph. It creates nodes in separate transactions using `+CALL { ... } IN TRANSACTIONS+`: @@ -440,7 +435,7 @@ It creates nodes in separate transactions using `+CALL { ... } IN TRANSACTIONS+` LOAD CSV FROM 'file:///friends.csv' AS line CALL { WITH line - CREATE (:Person {name: line[1], age: toInteger(line[2])}) + CREATE (:PERSON {name: line[1], age: toInteger(line[2])}) } IN TRANSACTIONS ---- @@ -606,20 +601,15 @@ The batch size of `2 ROWS` is an example given the small data set used here. For larger data sets, you might want to use larger batch sizes, such as `10000 ROWS`. ==== -=== Error behaviour [[txs_error_behaviour]] -Users can choose one of three different option flags to control the behaviour -in case of an error occurring in any of the inner transactions of `+CALL { ... } IN TRANSACTIONS+`: -* `ON ERROR CONTINUE` to ignore a recoverable error and continue the execution of subsequent inner transactions. -The outer transaction succeeds. -It will cause the expected variables from the failed inner query to be bound as null for that specific transaction. -* `ON ERROR BREAK` to ignore a recoverable error and stop the execution of subsequent inner transactions. The outer transaction succeeds. -It will cause expected variables from the failed inner query to be bound as null for all onward transactions (including the failed one). -* `ON ERROR FAIL` to acknowledge a recoverable error and stop the execution of subsequent inner transactions. The outer transaction fails. This is the default behaviour if no flag is explicitly specified. +=== Errors + +If an error occurs in `+CALL { ... } IN TRANSACTIONS+` the entire query fails and +both the current inner transaction and the outer transaction are rolled back. [IMPORTANT] ==== -On error, any previously committed inner transactions remain committed, and are not rolled back. Any failed inner transactions are rolled back. +On error, any previously committed inner transactions remain committed, and are not rolled back. ==== In the following example, the last subquery execution in the second inner transaction fails @@ -631,7 +621,7 @@ due to division by zero. UNWIND [4, 2, 1, 0] AS i CALL { WITH i - CREATE (:Person {num: 100/i}) + CREATE (:Example {num: 100/i}) } IN TRANSACTIONS OF 2 ROWS RETURN i ---- @@ -647,7 +637,7 @@ When the failure occurred, the first transaction had already been committed, so .Query [source, cypher] ---- -MATCH (e:Person) +MATCH (e:Example) RETURN e.num ---- @@ -660,235 +650,6 @@ RETURN e.num 1+d|Rows: 2 |=== -In the following example, `ON ERROR CONTINUE` is used after a failed inner transaction to execute the remaining inner transactions and not fail the outer transaction: - -.Query -[source, cypher] ----- -UNWIND [1, 0, 2, 4] AS i -CALL { - WITH i - CREATE (n:Person {num: 100/i}) // Note, fails when i = 0 - RETURN n -} IN TRANSACTIONS - OF 1 ROW - ON ERROR CONTINUE -RETURN n.num; ----- - -.Result -[role="queryresult",options="header,footer",cols="1*>. - -After each execution of the inner query finishes (successfully or not), a status value is created that records information about the execution and the transaction that executed it: - -* If the inner execution produces one or more rows as output, then a binding to this status value is added to each row, under the selected variable name. -* If the inner execution fails then a single row is produced containing a binding to this status value under the selected variable, and null bindings for all variables that should have been returned by the inner query (if any). - -The status value is a map value with the following fields: - -* `started`: `true` when the inner transaction was started, `false` otherwise. -* `committed`, true when the inner transaction changes were successfully committed, false otherwise. -* `transactionId`: the inner transaction id, or null if the transaction was not started. -* `errorMessage`, the inner transaction error message, or null in case of no error. - -Example of reporting status with `ON ERROR CONTINUE`: - -.Query -[source, cypher, indent=0] ----- -UNWIND [1, 0, 2, 4] AS i -CALL { - WITH i - CREATE (n:Person {num: 100/i}) // Note, fails when i = 0 - RETURN n -} IN TRANSACTIONS - OF 1 ROW - ON ERROR CONTINUE - REPORT STATUS AS s -RETURN n.num, s; ----- - -.Result -[role="queryresult",options="header,footer",cols="2*