From: Lele Gaifax Date: Mon, 31 Dec 2018 02:16:11 +0000 (-0500) Subject: commit 1b774808c926665047bf353222ecd191679a95d1 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=74838dda2f7e7bd66fc597fd3f7cee1d245beecb;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git 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 (cherry picked from commit c0f9708fde39175c8695fdd87873464f516fdf98) (cherry picked from commit 7ec092063a7defe2b60d8f01b2eb3cda9dd28c90) --- diff --git a/README.unittests.rst b/README.unittests.rst index 28924531ed..c32837f780 100644 --- a/README.unittests.rst +++ b/README.unittests.rst @@ -23,7 +23,7 @@ Python 2.7 using an in-memory SQLite database:: The tox runner contains a series of target combinations that can run against various combinations of databases. The test suite can be -run against SQLite with "backend" tests also running against a Postgresql +run against SQLite with "backend" tests also running against a PostgreSQL database:: tox -e py36-sqlite-postgresql @@ -64,13 +64,13 @@ quickly allow for custom database connections. Example:: Above will run the tests in the test/sql/test_query.py file (a pretty good file for basic "does this database work at all?" to start with) against a -running Postgresql database at the given URL. +running PostgreSQL database at the given URL. The py.test frontend can also run tests against multiple kinds of databases at once - a large subset of tests are marked as "backend" tests, which will be run against each available backend, and additionally lots of tests are targeted at specific backends only, which only run if a matching backend is made available. -For example, to run the test suite against both Postgresql and MySQL at the same time:: +For example, to run the test suite against both PostgreSQL and MySQL at the same time:: py.test -n4 --db postgresql --db mysql diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst index 93812d5e2e..1ae1f32162 100644 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@ -217,7 +217,7 @@ ``_reset_exported()`` would corrupt the state of the object. This method is intended for selectable objects and is called by the ORM in some cases; an erroneous mapper configuration would could lead the - ORM to call this on on a :class:`.Table` object. + ORM to call this on a :class:`.Table` object. .. change:: :tags: bug, ext @@ -703,7 +703,7 @@ construct, when the target :class:`.Table` has Python-side defaults. The :class:`.Select` construct would compile standalone with the erroneous column present subsequent to compilation of the - :class:`.Insert`, and the the :class:`.Insert` statement itself would + :class:`.Insert`, and the :class:`.Insert` statement itself would fail on a second compile attempt due to duplicate bound parameters. .. change:: diff --git a/doc/build/changelog/changelog_11.rst b/doc/build/changelog/changelog_11.rst index dfb4abeb45..9f3e73303b 100644 --- a/doc/build/changelog/changelog_11.rst +++ b/doc/build/changelog/changelog_11.rst @@ -41,7 +41,7 @@ :tickets: 4208 :versions: 1.2.5, 1.3.0b1 - Fixed bug in Postgresql COLLATE / ARRAY adjustment first introduced + Fixed bug in PostgreSQL COLLATE / ARRAY adjustment first introduced in :ticket:`4006` where new behaviors in Python 3.7 regular expressions caused the fix to fail. @@ -129,7 +129,7 @@ :tags: bug, postgresql Added "TRUNCATE" to the list of keywords accepted by the - Postgresql dialect as an "autocommit"-triggering keyword. + PostgreSQL dialect as an "autocommit"-triggering keyword. Pull request courtesy Jacob Hayes. .. change:: @@ -249,7 +249,7 @@ :versions: 1.2.0b3 Fixed bug in :obj:`.array_agg` function where passing an argument - that is already of type :class:`.ARRAY`, such as a Postgresql + that is already of type :class:`.ARRAY`, such as a PostgreSQL :obj:`.postgresql.array` construct, would produce a ``ValueError``, due to the function attempting to nest the arrays. @@ -268,7 +268,7 @@ :tickets: 4074 :versions: 1.2.0b3 - Fixed bug in Postgresql :meth:`.postgresql.dml.Insert.on_conflict_do_update` + Fixed bug in PostgreSQL :meth:`.postgresql.dml.Insert.on_conflict_do_update` which would prevent the insert statement from being used as a CTE, e.g. via :meth:`.Insert.cte`, within another statement. @@ -465,12 +465,12 @@ :tickets: 4005 :versions: 1.2.0b1 - Continuing with the fix that correctly handles Postgresql + Continuing with the fix that correctly handles PostgreSQL version string "10devel" released in 1.1.8, an additional regexp bump to handle version strings of the form "10beta1". While - Postgresql now offers better ways to get this information, we + PostgreSQL now offers better ways to get this information, we are sticking w/ the regexp at least through 1.1.x for the least - amount of risk to compatibility w/ older or alternate Postgresql + amount of risk to compatibility w/ older or alternate PostgreSQL databases. .. change:: 4006 @@ -632,7 +632,7 @@ Changed the mechanics of :class:`.ResultProxy` to unconditionally delay the "autoclose" step until the :class:`.Connection` is done - with the object; in the case where Postgresql ON CONFLICT with + with the object; in the case where PostgreSQL ON CONFLICT with RETURNING returns no rows, autoclose was occurring in this previously non-existent use case, causing the usual autocommit behavior that occurs unconditionally upon INSERT/UPDATE/DELETE to fail. @@ -668,7 +668,7 @@ :tags: bug, postgresql :versions: 1.2.0b1 - Added support for parsing the Postgresql version string for + Added support for parsing the PostgreSQL version string for a development version like "PostgreSQL 10devel". Pull request courtesy Sean McCully. @@ -781,7 +781,7 @@ :tickets: 3804 Added regular expressions for the "IMPORT FOREIGN SCHEMA", - "REFRESH MATERIALIZED VIEW" Postgresql statements so that they + "REFRESH MATERIALIZED VIEW" PostgreSQL statements so that they autocommit when invoked via a connection or engine without an explicit transaction. Pull requests courtesy Frazer McLean and Paweł Stiasny. @@ -835,7 +835,7 @@ :tags: bug, postgresql :tickets: 3900 - Fixed bug in Postgresql :class:`.ExcludeConstraint` where the + Fixed bug in PostgreSQL :class:`.ExcludeConstraint` where the "whereclause" and "using" parameters would not be copied during an operation like :meth:`.Table.tometadata`. @@ -1126,7 +1126,7 @@ pymysql dialects. This feature is available via the :paramref:`.Connection.execution_options.stream_results` flag as well as the ``server_side_cursors=True`` dialect argument in the - same way that it has been for psycopg2 on Postgresql. Pull request + same way that it has been for psycopg2 on PostgreSQL. Pull request courtesy Roman Podoliaka. .. change:: @@ -1172,7 +1172,7 @@ :tags: bug, postgresql :tickets: 3835 - Postgresql table reflection will ensure that the + PostgreSQL table reflection will ensure that the :paramref:`.Column.autoincrement` flag is set to False when reflecting a primary key column that is not of an :class:`.Integer` datatype, even if the default is related to an integer-generating sequence. diff --git a/doc/build/changelog/migration_11.rst b/doc/build/changelog/migration_11.rst index aa751a6c3e..43d3dab379 100644 --- a/doc/build/changelog/migration_11.rst +++ b/doc/build/changelog/migration_11.rst @@ -1652,9 +1652,9 @@ retained as None/NULL. integer values, such as strings, also changed in behavior such that the string value ``"0"`` would be interpreted as "true", but only on backends that don't have a native boolean datatype - on "native boolean" backends - like Postgresql, the string value ``"0"`` is passed directly to the driver + like PostgreSQL, the string value ``"0"`` is passed directly to the driver and is interpreted as "false". This is an inconsistency that did not occur - with the previous implementation.It should be noted that passing strings or + with the previous implementation. It should be noted that passing strings or any other value outside of ``None``, ``True``, ``False``, ``1``, ``0`` to the :class:`.Boolean` datatype is **not supported** and version 1.2 will raise an error for this scenario (or possibly just emit a warning, TBD). @@ -2220,7 +2220,7 @@ expressions to :meth:`.Query.distinct`, the above "column adding" logic is disabled entirely. When the query is being bundled into a subquery for the purposes of -joined eager loading, the "augment column list" rules are are necessarily +joined eager loading, the "augment column list" rules are necessarily more aggressive so that the ORDER BY can still be satisfied, so this case remains unchanged. diff --git a/doc/build/orm/cascades.rst b/doc/build/orm/cascades.rst index 0a0f23a707..8886621ae9 100644 --- a/doc/build/orm/cascades.rst +++ b/doc/build/orm/cascades.rst @@ -131,7 +131,7 @@ delete The ``delete`` cascade indicates that when a "parent" object is marked for deletion, its related "child" objects should also be marked -for deletion. If for example we we have a relationship ``User.addresses`` +for deletion. If for example we have a relationship ``User.addresses`` with ``delete`` cascade configured:: class User(Base): diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst index 7c1db2dd96..c25c68e17e 100644 --- a/doc/build/orm/persistence_techniques.rst +++ b/doc/build/orm/persistence_techniques.rst @@ -345,7 +345,7 @@ outside of the database's usual autoincrement routine. In this case, we have to make sure SQLAlchemy can "pre-execute" the default, which means it has to be an explicit SQL expression. -.. note:: This section will will illustrate multiple recipes involving +.. note:: This section will illustrate multiple recipes involving datetime values for MySQL and SQLite, since the datetime datatypes on these two backends have additional idiosyncratic requirements that are useful to illustrate. Keep in mind however that SQLite and MySQL require an explicit diff --git a/doc/build/orm/session_transaction.rst b/doc/build/orm/session_transaction.rst index bd06286a6e..6b33a68781 100644 --- a/doc/build/orm/session_transaction.rst +++ b/doc/build/orm/session_transaction.rst @@ -150,7 +150,7 @@ methods are called. The :class:`.Session` also features an older legacy mode of use called **autocommit mode**, where a transaction is not started implicitly, and unless -the the :meth:`.Session.begin` method is invoked, the :class:`.Session` will +the :meth:`.Session.begin` method is invoked, the :class:`.Session` will perform each database operation on a new connection checked out from the connection pool, which is then released back to the pool immediately after the operation completes. This refers to diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py index 5117025fb0..7f105f1d67 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 diff --git a/lib/sqlalchemy/sql/sqltypes.py b/lib/sqlalchemy/sql/sqltypes.py index bd9c426261..eef8276f2e 100644 --- a/lib/sqlalchemy/sql/sqltypes.py +++ b/lib/sqlalchemy/sql/sqltypes.py @@ -1810,13 +1810,13 @@ class JSON(Indexable, TypeEngine): Index operations return an expression object whose type defaults to :class:`.JSON` by default, so that further JSON-oriented instructions may be called upon the result type. Note that there are backend-specific - idiosyncracies here, including that the Postgresql database does not generally + idiosyncracies here, including that the PostgreSQL database does not generally compare a "json" to a "json" structure without type casts. These idiosyncracies - can be accommodated in a backend-neutral way by by making explicit use + can be accommodated in a backend-neutral way by making explicit use of the :func:`.cast` and :func:`.type_coerce` constructs. Comparison of specific index elements of a :class:`.JSON` object - to other objects work best if the **left hand side is CAST to a string** - and the **right hand side is rendered as a json string**; a future SQLAlchemy + to other objects works best if the **left hand side is CAST to a string** + and the **right hand side is rendered as a JSON string**; a future SQLAlchemy feature such as a generic "astext" modifier may simplify this at some point: * **Compare an element of a JSON structure to a string**:: diff --git a/lib/sqlalchemy/testing/plugin/plugin_base.py b/lib/sqlalchemy/testing/plugin/plugin_base.py index 6b08ef49ab..c8a8ba58c6 100644 --- a/lib/sqlalchemy/testing/plugin/plugin_base.py +++ b/lib/sqlalchemy/testing/plugin/plugin_base.py @@ -66,7 +66,7 @@ def setup_options(make_option): make_option("--nomemory", action="store_true", dest="nomemory", help="Don't run memory profiling tests") make_option("--postgresql-templatedb", type="string", - help="name of template database to use for Postgresql " + help="name of template database to use for PostgreSQL " "CREATE DATABASE (defaults to current database)") make_option("--low-connections", action="store_true", dest="low_connections",