From 71f14f6de8ee1865fd68d7989f751eed95dde719 Mon Sep 17 00:00:00 2001 From: Karthikeyan Singaravelan Date: Sun, 9 Aug 2020 10:02:57 +0000 Subject: [PATCH] Fix typos --- doc/build/changelog/changelog_09.rst | 4 ++-- doc/build/changelog/changelog_10.rst | 4 ++-- doc/build/changelog/changelog_11.rst | 2 +- doc/build/changelog/changelog_12.rst | 2 +- doc/build/changelog/changelog_13.rst | 14 +++++++------- doc/build/changelog/migration_13.rst | 2 +- doc/build/changelog/migration_14.rst | 6 +++--- doc/build/changelog/unreleased_13/5481.rst | 2 +- doc/build/changelog/unreleased_14/5074.rst | 2 +- doc/build/changelog/unreleased_14/5401.rst | 4 ++-- doc/build/core/connections.rst | 4 ++-- doc/build/core/tutorial.rst | 2 +- doc/build/errors.rst | 4 ++-- doc/build/glossary.rst | 2 +- doc/build/orm/cascades.rst | 2 +- doc/build/orm/session_basics.rst | 12 ++++++------ doc/build/orm/session_transaction.rst | 4 ++-- lib/sqlalchemy/dialects/oracle/base.py | 2 +- lib/sqlalchemy/sql/operators.py | 2 +- 19 files changed, 38 insertions(+), 38 deletions(-) diff --git a/doc/build/changelog/changelog_09.rst b/doc/build/changelog/changelog_09.rst index afb0b14be6..620b65c8c7 100644 --- a/doc/build/changelog/changelog_09.rst +++ b/doc/build/changelog/changelog_09.rst @@ -772,7 +772,7 @@ when True indicates that the Python ``None`` value should be persisted as SQL NULL, rather than JSON-encoded ``'null'``. - Retrival of NULL as None is also repaired for DBAPIs other than + Retrieval of NULL as None is also repaired for DBAPIs other than psycopg2, namely pg8000. .. change:: @@ -2566,7 +2566,7 @@ Added new argument ``include_backrefs=True`` to the :func:`.validates` function; when set to False, a validation event - will not be triggered if the event was initated as a backref to + will not be triggered if the event was initiated as a backref to an attribute operation from the other side. .. seealso:: diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst index 7058a2ae23..90a71d9f17 100644 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@ -136,7 +136,7 @@ .. change:: :tags: bug, mssql - :tickes: 3791 + :tickets: 3791 :versions: 1.1.0 Added error code 20017 "unexpected EOF from the server" to the list of @@ -3275,7 +3275,7 @@ Removing (or adding) an event listener at the same time that the event is being run itself, either from inside the listener or from a concurrent thread, now raises a RuntimeError, as the collection used is - now an instance of ``colletions.deque()`` and does not support changes + now an instance of ``collections.deque()`` and does not support changes while being iterated. Previously, a plain Python list was used where removal from inside the event itself would produce silent failures. diff --git a/doc/build/changelog/changelog_11.rst b/doc/build/changelog/changelog_11.rst index 013efce385..1988b69b30 100644 --- a/doc/build/changelog/changelog_11.rst +++ b/doc/build/changelog/changelog_11.rst @@ -925,7 +925,7 @@ .. change:: 3882 :tags: bug, sql - :tikets: 3882 + :tickets: 3882 Fixed bug originally introduced in 0.9 via :ticket:`1068` where order_by() would order by the label name based on name diff --git a/doc/build/changelog/changelog_12.rst b/doc/build/changelog/changelog_12.rst index 38f6fd5fa5..6dc7d7f887 100644 --- a/doc/build/changelog/changelog_12.rst +++ b/doc/build/changelog/changelog_12.rst @@ -296,7 +296,7 @@ .. change:: :tags: bug, orm - :tickests: 4400 + :tickets: 4400 Fixed bug where chaining of mapper options using :meth:`.RelationshipProperty.of_type` in conjunction with a chained option diff --git a/doc/build/changelog/changelog_13.rst b/doc/build/changelog/changelog_13.rst index 1118e043aa..140c36ad65 100644 --- a/doc/build/changelog/changelog_13.rst +++ b/doc/build/changelog/changelog_13.rst @@ -1019,7 +1019,7 @@ Fixed issue where by if the "begin" of a transaction failed at the Core engine/connection level, such as due to network error or database is locked for some transactional recipes, within the context of the :class:`.Session` - procuring that connection from the conneciton pool and then immediately + procuring that connection from the connection pool and then immediately returning it, the ORM :class:`.Session` would not close the connection despite this connection not being stored within the state of that :class:`.Session`. This would lead to the connection being cleaned out by @@ -1550,7 +1550,7 @@ by table name only without the column names would not correctly be reflected as far as setting up the "referred columns", since SQLite's PRAGMA does not report on these columns if they weren't given explicitly. - For some reason this was harcoded to assume the name of the local column, + For some reason this was hardcoded to assume the name of the local column, which might work for some cases but is not correct. The new approach reflects the primary key of the referred table and uses the constraint columns list as the referred columns list, if the remote column(s) aren't @@ -1582,7 +1582,7 @@ Added support for reflection of CHECK constraints that include the special PostgreSQL qualifier "NOT VALID", which can be present for CHECK - constraints that were added to an exsiting table with the directive that + constraints that were added to an existing table with the directive that they not be applied to existing data in the table. The PostgreSQL dictionary for CHECK constraints as returned by :meth:`_reflection.Inspector.get_check_constraints` may include an additional entry @@ -1608,7 +1608,7 @@ The dialects that support json are supposed to take arguments ``json_serializer`` and ``json_deserializer`` at the create_engine() level, - however the SQLite dialect calls them ``_json_serilizer`` and + however the SQLite dialect calls them ``_json_serializer`` and ``_json_deserilalizer``. The names have been corrected, the old names are accepted with a change warning, and these parameters are now documented as :paramref:`_sa.create_engine.json_serializer` and @@ -1915,7 +1915,7 @@ Fixed an unlikely issue where the "corresponding column" routine for unions and other :class:`_selectable.CompoundSelect` objects could return the wrong column in - some overlapping column situtations, thus potentially impacting some ORM + some overlapping column situations, thus potentially impacting some ORM operations when set operations are in use, if the underlying :func:`_expression.select` constructs were used previously in other similar kinds of routines, due to a cached value not being cleared. @@ -1991,7 +1991,7 @@ :tags: bug, orm, py3k :tickets: 4674 - Replaced the Python compatbility routines for ``getfullargspec()`` with a + Replaced the Python compatibility routines for ``getfullargspec()`` with a fully vendored version from Python 3.3. Originally, Python was emitting deprecation warnings for this function in Python 3.8 alphas. While this change was reverted, it was observed that Python 3 implementations for @@ -2095,7 +2095,7 @@ :tickets: 4695 Fixed issue where the :paramref:`.AttributeEvents.active_history` flag - would not be set for an event listener that propgated to a subclass via the + would not be set for an event listener that propagated to a subclass via the :paramref:`.AttributeEvents.propagate` flag. This bug has been present for the full span of the :class:`.AttributeEvents` system. diff --git a/doc/build/changelog/migration_13.rst b/doc/build/changelog/migration_13.rst index e7c35c02c3..c7506ee77f 100644 --- a/doc/build/changelog/migration_13.rst +++ b/doc/build/changelog/migration_13.rst @@ -1408,7 +1408,7 @@ Once Python 3 was introduced, DBAPIs began to start supporting Unicode more fully, and more importantly, by default. However, the conditions under which a particular DBAPI would or would not return Unicode data from a result, as well as accept Python Unicode values as parameters, remained extremely complicated. -This was the beginning of the obsolesence of the "convert_unicode" flags, +This was the beginning of the obsolescence of the "convert_unicode" flags, because they were no longer sufficient as a means of ensuring that encode/decode was occurring only where needed and not where it wasn't needed. Instead, "convert_unicode" started to be automatically detected by dialects. diff --git a/doc/build/changelog/migration_14.rst b/doc/build/changelog/migration_14.rst index 4207e4e813..5753cb089d 100644 --- a/doc/build/changelog/migration_14.rst +++ b/doc/build/changelog/migration_14.rst @@ -1611,7 +1611,7 @@ cascade_backrefs behavior deprecated for removal in 2.0 SQLAlchemy has long had a behavior of cascading objects into the :class:`_orm.Session` based on backref assignment. Given ``User`` below already in a :class:`_orm.Session`, assigning it to the ``Address.user`` -attribute of an ``Address`` object, assuming a bidrectional relationship +attribute of an ``Address`` object, assuming a bidirectional relationship is set up, would mean that the ``Address`` also gets put into the :class:`_orm.Session` at that point:: @@ -2118,7 +2118,7 @@ rows that are generated by RETURNING as an aggregated list. The psycopg2 dialect will now retrieve this list if the given :func:`_sql.insert` construct requests returning via the :meth:`.Insert.returning` method or similar methods intended to return generated defaults; the rows are then installed in the -result so that they are retreieved as though they came from the cursor +result so that they are retrieved as though they came from the cursor directly. This allows tools like the ORM to use batched inserts in all cases, which is expected to provide a dramatic performance improvement. @@ -2141,7 +2141,7 @@ with the following changes: * RETURNING support is enabled for ``"values_only"`` and ``"values"`` for INSERT statements. The psycopg2 dialect will receive the rows back from psycopg2 using the fetch=True flag and install them into the result - set as though they came directly from the cursor (which they ulimately did, + set as though they came directly from the cursor (which they ultimately did, however psycopg2's extension function has aggregated multiple batches into one list). diff --git a/doc/build/changelog/unreleased_13/5481.rst b/doc/build/changelog/unreleased_13/5481.rst index 2ebac73bf7..7d7666a72f 100644 --- a/doc/build/changelog/unreleased_13/5481.rst +++ b/doc/build/changelog/unreleased_13/5481.rst @@ -4,5 +4,5 @@ The MySQL dialect will render FROM DUAL for a SELECT statement that has no FROM clause but has a WHERE clause. This allows things like "SELECT 1 WHERE - EXISTS (subuqery)" kinds of queries to be used as well as other use cases. + EXISTS (subquery)" kinds of queries to be used as well as other use cases. diff --git a/doc/build/changelog/unreleased_14/5074.rst b/doc/build/changelog/unreleased_14/5074.rst index 95e93b3dce..3159ade500 100644 --- a/doc/build/changelog/unreleased_14/5074.rst +++ b/doc/build/changelog/unreleased_14/5074.rst @@ -2,7 +2,7 @@ :tags: bug, orm :tickets: 5074 - The :class:`.Session` object no longer initates a + The :class:`.Session` object no longer initiates a :class:`.SessionTransaction` object immediately upon construction or after the previous transaction is closed; instead, "autobegin" logic now initiates the new :class:`.SessionTransaction` on demand when it is next diff --git a/doc/build/changelog/unreleased_14/5401.rst b/doc/build/changelog/unreleased_14/5401.rst index 01098053f5..aa85511b4d 100644 --- a/doc/build/changelog/unreleased_14/5401.rst +++ b/doc/build/changelog/unreleased_14/5401.rst @@ -1,10 +1,10 @@ .. change:: - :tags: peformance, postgresql + :tags: performance, postgresql :tickets: 5401 The psycopg2 dialect now defaults to using the very performant ``execute_values()`` psycopg2 extension for compiled INSERT statements, - and also impements RETURNING support when this extension is used. This + and also implements RETURNING support when this extension is used. This allows INSERT statements that even include an autoincremented SERIAL or IDENTITY value to run very fast while still being able to return the newly generated primary key values. The ORM will then integrate this diff --git a/doc/build/core/connections.rst b/doc/build/core/connections.rst index 0e0170d435..6c8e51b7bb 100644 --- a/doc/build/core/connections.rst +++ b/doc/build/core/connections.rst @@ -248,7 +248,7 @@ and have no effect. Instead, each statement invoked upon the connection will commit any changes automatically; it sometimes also means that the connection itself will use fewer server-side database resources. For this reason and others, "autocommit" -mode is often desirable for non-tranasctional applications that need to read +mode is often desirable for non-transactional applications that need to read individual tables or rows in isolation of a true ACID transaction. SQLAlchemy dialects can support these isolation levels as well as autocommit to @@ -271,7 +271,7 @@ certain backend, an error is raised. For example, to force REPEATABLE READ on a specific connection:: - with engine.connect().execution_options(isolation_level="REPEATBLE READ") as connection: + with engine.connect().execution_options(isolation_level="REPEATABLE READ") as connection: connection.execute() The :paramref:`_engine.Connection.execution_options.isolation_level` option diff --git a/doc/build/core/tutorial.rst b/doc/build/core/tutorial.rst index b8faed126b..3f4d37d0e2 100644 --- a/doc/build/core/tutorial.rst +++ b/doc/build/core/tutorial.rst @@ -445,7 +445,7 @@ access: name: wendy ; fullname: Wendy Williams To access columns via name using strings, either when the column name is -progammatically generated, or contains non-ascii characters, the +programmatically generated, or contains non-ascii characters, the :attr:`.Row._mapping` view may be used that provides dictionary-like access: .. sourcecode:: pycon+sql diff --git a/doc/build/errors.rst b/doc/build/errors.rst index d4659101ac..ab9e018d96 100644 --- a/doc/build/errors.rst +++ b/doc/build/errors.rst @@ -128,7 +128,7 @@ refers to the :paramref:`_schema.MetaData.bind` parameter on the :class:`_schema.MetaData` object that in turn allows objects like the ORM :class:`_orm.Session` to associate a particular mapped class with an :class:`_orm.Engine`. In SQLAlchemy 2.0, the :class:`_orm.Session` must be -linked to each :class:`_orm.Engine` directly. That is, instead of instantating +linked to each :class:`_orm.Engine` directly. That is, instead of instantiating the :class:`_orm.Session` or :class:`_orm.sessionmaker` without any arguments, and associating the :class:`_engine.Engine` with the :class:`_schema.MetaData`:: @@ -1054,7 +1054,7 @@ Instance is already associated with an instance of via its --------------------------------------------------------------------------------------------------------------------------------------------- -This error is emited when the :paramref:`_orm.relationship.single_parent` flag +This error is emitted when the :paramref:`_orm.relationship.single_parent` flag is used, and more than one object is assigned as the "parent" of an object at once. diff --git a/doc/build/glossary.rst b/doc/build/glossary.rst index 82e81aad98..d85725b147 100644 --- a/doc/build/glossary.rst +++ b/doc/build/glossary.rst @@ -117,7 +117,7 @@ Glossary SQLAlchemy Core which will behave differently when used in an ORM context. - SQLAlchemy allows Core consrtucts such as :class:`_sql.Select` objects + SQLAlchemy allows Core constructs such as :class:`_sql.Select` objects to participate in a "plugin" system, which can inject additional behaviors and features into the object that are not present by default. diff --git a/doc/build/orm/cascades.rst b/doc/build/orm/cascades.rst index 8631dedbe6..3f06b34c2f 100644 --- a/doc/build/orm/cascades.rst +++ b/doc/build/orm/cascades.rst @@ -246,7 +246,7 @@ association:: Above, when a ``Parent`` object is marked for deletion using :meth:`_orm.Session.delete`, the flush process will as usual delete -the assocation rows from the ``association`` table, however per cascade +the associated rows from the ``association`` table, however per cascade rules it will also delete all related ``Child`` rows. diff --git a/doc/build/orm/session_basics.rst b/doc/build/orm/session_basics.rst index f63b7abd08..ecf76ae63e 100644 --- a/doc/build/orm/session_basics.rst +++ b/doc/build/orm/session_basics.rst @@ -110,7 +110,7 @@ When you write your application, the :class:`.sessionmaker` factory should be globally scoped, the same way as the :class:`_engine.Engine` object created by :func:`_sa.create_engine` is also typically globally scoped. As these objects are both factories, they -can be used by any number of functions and threads simultaenously. +can be used by any number of functions and threads simultaneously. .. seealso:: @@ -391,7 +391,7 @@ To emit a bulk UPDATE in :term:`1.x style`, the :meth:`_query.Query.update` meth may be used:: session.query(User).filter(User.nane == "squidward").\ - update({"name": "spongebob"}, syncronize_session="fetch") + update({"name": "spongebob"}, synchronize_session="fetch") Above, an UPDATE will be emitted against all rows that match the name "squidward" and be updated to the name "spongebob". The @@ -410,7 +410,7 @@ be configured with :paramref:`_orm.Session.future` set to ``True``:: from sqlalchemy import update stmt = update(User).where(User.nane == "squidward").values(name="spongebob")).\ - execution_options(syncronize_session="fetch") + execution_options(synchronize_session="fetch") session.execute(stmt) @@ -424,7 +424,7 @@ within the :class:`_orm.Session` will be marked as deleted and expunged. Bulk delete, :term:`1.x style`:: session.query(User).filter(User.nane == "squidward").\ - delete(syncronize_session="fetch") + delete(synchronize_session="fetch") Bulk delete, :term:`2.0 style`. The :meth:`_orm.Session` must be configured with :paramref:`_orm.Session.future` set to ``True``:: @@ -432,7 +432,7 @@ be configured with :paramref:`_orm.Session.future` set to ``True``:: session = Session(future=True) from sqlalchemy import delete - stmt = delete(User).where(User.nane == "squidward").execution_options(syncronize_session="fetch") + stmt = delete(User).where(User.nane == "squidward").execution_options(synchronize_session="fetch") session.execute(stmt) @@ -478,7 +478,7 @@ values for ``synchronize_session`` are supported: The bulk UPDATE and DELETE features bypass ORM unit-of-work automation in favor being able to emit a single UPDATE or DELETE statement at once - without complextiy. + without complexity. * The operations do not offer in-Python cascading of relationships - it is assumed that ON UPDATE CASCADE and/or diff --git a/doc/build/orm/session_transaction.rst b/doc/build/orm/session_transaction.rst index 6bef0cee60..4cffdc4a32 100644 --- a/doc/build/orm/session_transaction.rst +++ b/doc/build/orm/session_transaction.rst @@ -370,7 +370,7 @@ The :meth:`_orm.Session.begin` method and the session's "autobegin" process use the same sequence of steps to begin the transaction. This includes that the :meth:`_orm.SessionEvents.after_transaction_create` event is invoked when it occurs; this hook is used by frameworks in order to integrate their -own trasactional processes with that of the ORM :class:`_orm.Session`. +own transactional processes with that of the ORM :class:`_orm.Session`. .. _session_subtransactions: @@ -387,7 +387,7 @@ Migrating from the "subtransaction" pattern The "subtransaction" pattern that was often used with autocommit mode is also deprecated in 1.4. This pattern allowed the use of the -:meth:`_orm.Session.begin` method when a tranasction were already begun, +:meth:`_orm.Session.begin` method when a transaction were already begun, resulting in a construct called a "subtransaction", which was essentially a block that would prevent the :meth:`_orm.Session.commit` method from actually committing. diff --git a/lib/sqlalchemy/dialects/oracle/base.py b/lib/sqlalchemy/dialects/oracle/base.py index 6f4df80683..7cb9aae57c 100644 --- a/lib/sqlalchemy/dialects/oracle/base.py +++ b/lib/sqlalchemy/dialects/oracle/base.py @@ -65,7 +65,7 @@ Valid values for ``isolation_level`` include: .. versionadded:: 1.3.16 added support for AUTOCOMMIT to the cx_oracle dialect - as well as the notion of a default isolation level, currently harcoded + as well as the notion of a default isolation level, currently hardcoded to "READ COMMITTED". .. seealso:: diff --git a/lib/sqlalchemy/sql/operators.py b/lib/sqlalchemy/sql/operators.py index 2d369cdf8a..bb773e2812 100644 --- a/lib/sqlalchemy/sql/operators.py +++ b/lib/sqlalchemy/sql/operators.py @@ -536,7 +536,7 @@ class ColumnOperators(Operators): In this calling form, the expression renders an "empty set" expression. These expressions are tailored to individual backends and are generaly trying to get an empty SELECT statement as a - subuqery. Such as on SQLite, the expression is:: + subquery. Such as on SQLite, the expression is:: WHERE col IN (SELECT 1 FROM (SELECT 1) WHERE 1!=1) -- 2.39.5