zstan commented on code in PR #13116:
URL: https://github.com/apache/ignite/pull/13116#discussion_r3208436416
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
Review Comment:
```suggestion
To ensure backward compatibility, transaction support is disabled by
default. To enable it, use the following configuration:
```
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
Review Comment:
```suggestion
The Calcite-based query engine supports SQL transactions with READ_COMMITTED
isolation.
```
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
+ <property name="transactionConfiguration">
+ <bean class="org.apache.ignite.configuration.TransactionConfiguration">
+ <property name="txAwareQueriesEnabled" value="true" />
+ ...
+ </bean>
+ </property>
+ ...
+</bean>
+----
+--
+
+The following API "transactional aware":
+
+* key-value API.
+* SQL queries with Calcite engine.
+* Scan queries.
+
+"Transactional aware" means:
+
+1. ACID in the same way as key-value API.
+2. Any data changed or removed by the query will not be visible to the
concurrent query until transaction committed.
+3. Any data changed by the query will be returned updated by subsequent
queries of the same transaction.
+4. And data removed by the query will not be returned by subsequent queries of
the same transaction.
+
+So, when `txAwareQueriesEnabled = true` you can:
Review Comment:
i\`d prefer not 1-st form, not "you" but smth like: With
`txAwareQueriesEnabled = true` become possible ...
Or
Setting txAwareQueriesEnabled = true enables the use of [feature]
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
+ <property name="transactionConfiguration">
+ <bean class="org.apache.ignite.configuration.TransactionConfiguration">
+ <property name="txAwareQueriesEnabled" value="true" />
+ ...
+ </bean>
+ </property>
+ ...
+</bean>
+----
+--
+
+The following API "transactional aware":
+
+* key-value API.
+* SQL queries with Calcite engine.
+* Scan queries.
+
+"Transactional aware" means:
+
+1. ACID in the same way as key-value API.
+2. Any data changed or removed by the query will not be visible to the
concurrent query until transaction committed.
+3. Any data changed by the query will be returned updated by subsequent
queries of the same transaction.
+4. And data removed by the query will not be returned by subsequent queries of
the same transaction.
Review Comment:
```suggestion
4. Any data removed by the query will not be returned by subsequent queries
of the same transaction.
```
may be :
Data deleted within a transaction will not be returned by subsequent queries
in that same transaction.
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
+ <property name="transactionConfiguration">
+ <bean class="org.apache.ignite.configuration.TransactionConfiguration">
+ <property name="txAwareQueriesEnabled" value="true" />
+ ...
+ </bean>
+ </property>
+ ...
+</bean>
+----
+--
+
+The following API "transactional aware":
+
+* key-value API.
+* SQL queries with Calcite engine.
+* Scan queries.
+
+"Transactional aware" means:
+
+1. ACID in the same way as key-value API.
+2. Any data changed or removed by the query will not be visible to the
concurrent query until transaction committed.
+3. Any data changed by the query will be returned updated by subsequent
queries of the same transaction.
+4. And data removed by the query will not be returned by subsequent queries of
the same transaction.
+
+So, when `txAwareQueriesEnabled = true` you can:
+
+* Perform INSERT, UPDATE, DELETE statements with regular transaction
guarantees.
+* Mix key-value, SQL and Scan queries to process same dataset.
+
+
+[NOTE]
+====
+[discrete]
+=== SELECT ... FOR UPDATE
+Currently, no locks are held by the UPDATE or SELECT statements.
+`SELECT ... FOR UPDATE` statement not supported.
Review Comment:
grammatically - it passed correctly, probably we need to reject this
constructions ? issue ? before we will fix it somehow ?
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
Review Comment:
what about java code configuration ?
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
+ <property name="transactionConfiguration">
+ <bean class="org.apache.ignite.configuration.TransactionConfiguration">
+ <property name="txAwareQueriesEnabled" value="true" />
+ ...
+ </bean>
+ </property>
+ ...
+</bean>
+----
+--
+
+The following API "transactional aware":
+
+* key-value API.
+* SQL queries with Calcite engine.
+* Scan queries.
+
+"Transactional aware" means:
+
+1. ACID in the same way as key-value API.
+2. Any data changed or removed by the query will not be visible to the
concurrent query until transaction committed.
Review Comment:
```suggestion
2. Any data modified or deleted within a transaction will not be visible to
concurrent transactions until it is committed.
```
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
+ <property name="transactionConfiguration">
+ <bean class="org.apache.ignite.configuration.TransactionConfiguration">
+ <property name="txAwareQueriesEnabled" value="true" />
+ ...
+ </bean>
+ </property>
+ ...
+</bean>
+----
+--
+
+The following API "transactional aware":
+
+* key-value API.
+* SQL queries with Calcite engine.
+* Scan queries.
+
+"Transactional aware" means:
+
+1. ACID in the same way as key-value API.
+2. Any data changed or removed by the query will not be visible to the
concurrent query until transaction committed.
+3. Any data changed by the query will be returned updated by subsequent
queries of the same transaction.
Review Comment:
don`t understand at all (
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
Review Comment:
PESSIMISTIC, READ_COMMITTED !! Not Optimistic
I think it also need to be mention that some kind of Frankenstein is
currently implemented, i.e :
```
try (Transaction tx = client.transactions().txStart(PESSIMISTIC,
READ_COMMITTED)) {
sql("some SQL ...
```
and not like:
```
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;
```
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
+ <property name="transactionConfiguration">
+ <bean class="org.apache.ignite.configuration.TransactionConfiguration">
+ <property name="txAwareQueriesEnabled" value="true" />
+ ...
+ </bean>
+ </property>
+ ...
+</bean>
+----
+--
+
+The following API "transactional aware":
+
+* key-value API.
+* SQL queries with Calcite engine.
+* Scan queries.
+
+"Transactional aware" means:
+
+1. ACID in the same way as key-value API.
+2. Any data changed or removed by the query will not be visible to the
concurrent query until transaction committed.
+3. Any data changed by the query will be returned updated by subsequent
queries of the same transaction.
+4. And data removed by the query will not be returned by subsequent queries of
the same transaction.
+
+So, when `txAwareQueriesEnabled = true` you can:
+
+* Perform INSERT, UPDATE, DELETE statements with regular transaction
guarantees.
+* Mix key-value, SQL and Scan queries to process same dataset.
+
+
+[NOTE]
+====
+[discrete]
+=== SELECT ... FOR UPDATE
+Currently, no locks are held by the UPDATE or SELECT statements.
+`SELECT ... FOR UPDATE` statement not supported.
+This mean, lost update are possible with transactional SQL queries in case
several transactions modifies one key concurrently.
Review Comment:
This means lost updates can occur when multiple transactions concurrently
modify the same key.
##########
docs/_docs/SQL/sql-calcite.adoc:
##########
@@ -483,3 +427,54 @@ Disables certain optimizer rules. This is an optimizer
level hint.
----
SELECT /*+ DISABLE_RULE('MergeJoinConverter') */ T1.* FROM TBL1 T1 JOIN TBL2
T2 ON T1.V1=T2.V1 WHERE T2.V2=?
----
+
+== Transactions [[transactions]]
+
+Transactions on `READ_COMMITTED` isolation level are supported for SQL queries
in Calcite query engine.
+To ensure backward compatibility transactions support disabled, by default.
+To enable, please, configure like the following:
+
+[tabs]
+--
+tab:XML[]
+[source,xml]
+----
+<bean class="org.apache.ignite.configuration.IgniteConfiguration">
+ <property name="transactionConfiguration">
+ <bean class="org.apache.ignite.configuration.TransactionConfiguration">
+ <property name="txAwareQueriesEnabled" value="true" />
+ ...
+ </bean>
+ </property>
+ ...
+</bean>
+----
+--
+
+The following API "transactional aware":
+
+* key-value API.
+* SQL queries with Calcite engine.
+* Scan queries.
+
+"Transactional aware" means:
+
+1. ACID in the same way as key-value API.
+2. Any data changed or removed by the query will not be visible to the
concurrent query until transaction committed.
+3. Any data changed by the query will be returned updated by subsequent
queries of the same transaction.
+4. And data removed by the query will not be returned by subsequent queries of
the same transaction.
+
+So, when `txAwareQueriesEnabled = true` you can:
+
+* Perform INSERT, UPDATE, DELETE statements with regular transaction
guarantees.
+* Mix key-value, SQL and Scan queries to process same dataset.
+
+
+[NOTE]
+====
+[discrete]
+=== SELECT ... FOR UPDATE
+Currently, no locks are held by the UPDATE or SELECT statements.
+`SELECT ... FOR UPDATE` statement not supported.
+This mean, lost update are possible with transactional SQL queries in case
several transactions modifies one key concurrently.
Review Comment:
update**s** are ot update **is**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
