Fix some typos in 1.1's changelog and migration sectionspr/287

2 files changed, 18 insertions, 18 deletions

diff --git a/doc/build/changelog/changelog_11.rst b/doc/build/changelog/changelog_11.rst
index 2bc96f247..455156f30 100644
--- a/doc/build/changelog/changelog_11.rst
+++ b/doc/build/changelog/changelog_11.rst
@@ -61,7 +61,7 @@
         ``validate_string=True`` is passed to the Enum; any other kind of object is
         still of course rejected.  While the immediate use
         is to allow comparisons to enums with LIKE, the fact that this
-        use exists indicates there may be more unknown-string-comparsion use
+        use exists indicates there may be more unknown-string-comparison use
         cases than we expected, which hints that perhaps there are some
         unknown string-INSERT cases too.
 
@@ -139,7 +139,7 @@
 
         Fixed an issue where a many-to-one change of an object from one
         parent to another could work inconsistently when combined with
-        an un-flushed modication of the foreign key attribute.  The attribute
+        an un-flushed modification of the foreign key attribute.  The attribute
         move now considers the database-committed value of the foreign key
         in order to locate the "previous" parent of the object being
         moved.   This allows events to fire off correctly including
@@ -433,7 +433,7 @@
         would still potentially cause persistence conflicts on the next
         transaction, because the instance would not be checked that it
         was expired.   This fix will resolve a large class of cases that
-        erronously cause the "New instance with identity X conflicts with
+        erroneously cause the "New instance with identity X conflicts with
         persistent instance Y" error.
 
         .. seealso::
@@ -1103,7 +1103,7 @@
         Additional fixes have been made regarding the value of ``None``
         in conjunction with the PostgreSQL :class:`.postgresql.JSON` type.  When
         the :paramref:`.JSON.none_as_null` flag is left at its default
-        value of ``False``, the ORM will now correctly insert the Json
+        value of ``False``, the ORM will now correctly insert the JSON
         "'null'" string into the column whenever the value on the ORM
         object is set to the value ``None`` or when the value ``None``
         is used with :meth:`.Session.bulk_insert_mappings`,
diff --git a/doc/build/changelog/migration_11.rst b/doc/build/changelog/migration_11.rst
index 550c76d92..d0f73b726 100644
--- a/doc/build/changelog/migration_11.rst
+++ b/doc/build/changelog/migration_11.rst
@@ -344,7 +344,7 @@ Improved Session state when a SAVEPOINT is cancelled by the database
 --------------------------------------------------------------------
 
 A common case with MySQL is that a SAVEPOINT is cancelled when a deadlock
-occurs within the transaction.  The :class:`.Session` has been modfied
+occurs within the transaction.  The :class:`.Session` has been modified
 to deal with this failure mode slightly more gracefully, such that the
 outer, non-savepoint transaction still remains usable::
 
@@ -703,12 +703,12 @@ would have to be compared during the merge.
 
 .. _change_3708:
 
-Fix involving many-to-one object moves with user-initiated foriegn key manipulations
+Fix involving many-to-one object moves with user-initiated foreign key manipulations
 ------------------------------------------------------------------------------------
 
 A bug has been fixed involving the mechanics of replacing a many-to-one
 reference to an object with another object.   During the attribute operation,
-the location of the object tha was previouly referred to now makes use of the
+the location of the object that was previously referred to now makes use of the
 database-committed foreign key value, rather than the current foreign key
 value.  The main effect of the fix is that a backref event towards a collection
 will fire off more accurately when a many-to-one change is made, even if the
@@ -751,7 +751,7 @@ improvement will now be apparent.
 
 .. _change_3662:
 
-Improvements to the Query.correlate method with polymoprhic entities
+Improvements to the Query.correlate method with polymorphic entities
 --------------------------------------------------------------------
 
 In recent SQLAlchemy versions, the SQL generated by many forms of
@@ -796,7 +796,7 @@ Using correlated subqueries against polymorphic mappings still has some
 unpolished edges.  If for example ``Person`` is polymorphically linked
 to a so-called "concrete polymorphic union" query, the above subquery
 may not correctly refer to this subquery.  In all cases, a way to refer
-to the "polyorphic" entity fully is to create an :func:`.aliased` object
+to the "polymorphic" entity fully is to create an :func:`.aliased` object
 from it first::
 
     # works with all SQLAlchemy versions and all types of polymorphic
@@ -962,7 +962,7 @@ 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
-more aggressive so that the ORDER BY can still be satisifed, so this case
+more aggressive so that the ORDER BY can still be satisfied, so this case
 remains unchanged.
 
 :ticket:`3641`
@@ -1175,7 +1175,7 @@ SQLAlchemy has always had the convenience feature of enabling the backend databa
 we mean that the database column will include whatever DDL directives the
 database provides in order to indicate an auto-incrementing integer identifier,
 such as the SERIAL keyword on PostgreSQL or AUTO_INCREMENT on MySQL, and additionally
-that the dialect will recieve these generated values from the execution
+that the dialect will receive these generated values from the execution
 of a :meth:`.Table.insert` construct using techniques appropriate to that
 backend.
 
@@ -1200,7 +1200,7 @@ disable this, one would have to turn off ``autoincrement`` on all columns::
     )
 
 With the new behavior, the composite primary key will not have autoincrement
-semantics unless a column is marked explcitly with ``autoincrement=True``::
+semantics unless a column is marked explicitly with ``autoincrement=True``::
 
     # column 'y' will be SERIAL/AUTO_INCREMENT/ auto-generating
     Table(
@@ -1457,7 +1457,7 @@ string values::
 Negative integer indexes accommodated by Core result rows
 ---------------------------------------------------------
 
-The :class:`.RowProxy` object now accomodates single negative integer indexes
+The :class:`.RowProxy` object now accommodates single negative integer indexes
 like a regular Python sequence, both in the pure Python and C-extension
 version.  Previously, negative values would only work in slices::
 
@@ -1472,9 +1472,9 @@ version.  Previously, negative values would only work in slices::
 The ``Enum`` type now does in-Python validation of values
 ---------------------------------------------------------
 
-To accomodate for Python native enumerated objects, as well as for edge
+To accommodate for Python native enumerated objects, as well as for edge
 cases such as that of where a non-native ENUM type is used within an ARRAY
-and a CHECK contraint is infeasible, the :class:`.Enum` datatype now adds
+and a CHECK constraint is infeasible, the :class:`.Enum` datatype now adds
 in-Python validation of input values when the :paramref:`.Enum.validate_strings`
 flag is used (1.1.0b2)::
 
@@ -2215,7 +2215,7 @@ The JSON cast() operation now requires ``.astext`` is called explicitly
 
 As part of the changes in :ref:`change_3503`, the workings of the
 :meth:`.ColumnElement.cast` operator on :class:`.postgresql.JSON` and
-:class:`.postgresql.JSONB` no longer implictly invoke the
+:class:`.postgresql.JSONB` no longer implicitly invoke the
 :attr:`.postgresql.JSON.Comparator.astext` modifier; Postgresql's JSON/JSONB types
 support CAST operations to each other without the "astext" aspect.
 
@@ -2463,7 +2463,7 @@ the version of SQLite noted in that migration note, 3.7.15.2, was the *last*
 version of SQLite to actually have this limitation!   The next release was
 3.7.16 and support for right nested joins was quietly added.   In 1.1, the work
 to identify the specific SQLite version and source commit where this change
-was made was done (SQlite's changelog refers to it with the cryptic phrase "Enhance
+was made was done (SQLite's changelog refers to it with the cryptic phrase "Enhance
 the query optimizer to exploit transitive join constraints" without linking
 to any issue number, change number, or further explanation), and the workarounds
 present in this change are now lifted for SQLite when the DBAPI reports
@@ -2505,7 +2505,7 @@ Improved Support for Remote Schemas
 The SQLite dialect now implements :meth:`.Inspector.get_schema_names`
 and additionally has improved support for tables and indexes that are
 created and reflected from a remote schema, which in SQLite is a
-dataase that is assigned a name via the ``ATTACH`` statement; previously,
+database that is assigned a name via the ``ATTACH`` statement; previously,
 the``CREATE INDEX`` DDL didn't work correctly for a schema-bound table
 and the :meth:`.Inspector.get_foreign_keys` method will now indicate the
 given schema in the results.  Cross-schema foreign keys aren't supported.