Fix typos

19 files changed, 38 insertions, 38 deletions

diff --git a/doc/build/changelog/changelog_09.rst b/doc/build/changelog/changelog_09.rst
index afb0b14be..620b65c8c 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 7058a2ae2..90a71d9f1 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 013efce38..1988b69b3 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(<some Label()>) 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 38f6fd5fa..6dc7d7f88 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 1118e043a..140c36ad6 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 e7c35c02c..c7506ee77 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 4207e4e81..5753cb089 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 2ebac73bf..7d7666a72 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 95e93b3dc..3159ade50 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 01098053f..aa85511b4 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 0e0170d43..6c8e51b7b 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(<statement>)
 
 The :paramref:`_engine.Connection.execution_options.isolation_level` option
diff --git a/doc/build/core/tutorial.rst b/doc/build/core/tutorial.rst
index b8faed126..3f4d37d0e 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 d4659101a..ab9e018d9 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 <instance> is already associated with an instance of <instance> 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 82e81aad9..d85725b14 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 8631dedbe..3f06b34c2 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 f63b7abd0..ecf76ae63 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 6bef0cee6..4cffdc4a3 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 6f4df8068..7cb9aae57 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 2d369cdf8..bb773e281 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)