From c0f9708fde39175c8695fdd87873464f516fdf98 Mon Sep 17 00:00:00 2001 From: Lele Gaifax Date: Sun, 30 Dec 2018 21:16:11 -0500 Subject: commit 1b774808c926665047bf353222ecd191679a95d1 Author: Lele Gaifax Date: Tue Dec 25 12:35:41 2018 +0100 Consistently use "PostgreSQL", fixing also a few doc glitches commit 0e382aaee4427193926f0dc10ad29056bc12c85e Author: Lele Gaifax Date: Tue Dec 25 12:08:49 2018 +0100 Remove duplicated words Change-Id: Iaa586b9412f46a50fe6ff3bbb92e07d6cb1905c8 --- lib/sqlalchemy/dialects/sqlite/base.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'lib/sqlalchemy/dialects/sqlite/base.py') diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py index 566814375..c487af898 100644 --- a/lib/sqlalchemy/dialects/sqlite/base.py +++ b/lib/sqlalchemy/dialects/sqlite/base.py @@ -189,7 +189,7 @@ The other axis along which SQLite's transactional locking is impacted is via the nature of the ``BEGIN`` statement used. The three varieties are "deferred", "immediate", and "exclusive", as described at `BEGIN TRANSACTION `_. A straight -``BEGIN`` statement uses the "deferred" mode, where the the database file is +``BEGIN`` statement uses the "deferred" mode, where the database file is not locked until the first read or write operation, and read access remains open to other transactions until the first write operation. But again, it is critical to note that the pysqlite driver interferes with this behavior -- cgit v1.2.1