| @@ -927,14 +927,6 @@ By default, the :mod:`sqlite3` module opens transactions implicitly before a |
|
|
| 927 |
927 |
Data Modification Language (DML) statement (i.e. |
| 928 |
928 |
``INSERT``/``UPDATE``/``DELETE``/``REPLACE``). |
| 929 |
929 |
|
| 930 |
|
-So if you are within a transaction and issue a command like ``CREATE TABLE |
| 931 |
|
-...``, ``VACUUM``, ``PRAGMA``, the :mod:`sqlite3` module will commit implicitly |
| 932 |
|
-before executing that command. There are two reasons for doing that. The first |
| 933 |
|
-is that some of these commands don't work within transactions. The other reason |
| 934 |
|
-is that sqlite3 needs to keep track of the transaction state (if a transaction |
| 935 |
|
-is active or not). The current transaction state is exposed through the |
| 936 |
|
-:attr:`Connection.in_transaction` attribute of the connection object. |
| 937 |
|
- |
| 938 |
930 |
You can control which kind of ``BEGIN`` statements sqlite3 implicitly executes |
| 939 |
931 |
(or none at all) via the *isolation_level* parameter to the :func:`connect` |
| 940 |
932 |
call, or via the :attr:`isolation_level` property of connections. |
| @@ -945,6 +937,9 @@ Otherwise leave it at its default, which will result in a plain "BEGIN" |
|
|
| 945 |
937 |
statement, or set it to one of SQLite's supported isolation levels: "DEFERRED", |
| 946 |
938 |
"IMMEDIATE" or "EXCLUSIVE". |
| 947 |
939 |
|
|
940 |
+The current transaction state is exposed through the |
|
941 |
+:attr:`Connection.in_transaction` attribute of the connection object. |
|
942 |
+ |
| 948 |
943 |
.. versionchanged:: 3.6 |
| 949 |
944 |
:mod:`sqlite3` used to implicitly commit an open transaction before DDL |
| 950 |
945 |
statements. This is no longer the case. |