From ae7ef6f6106ec85075f611f6488d42a82ae6c3de Mon Sep 17 00:00:00 2001 From: Lele Gaifax Date: Sat, 2 Jul 2016 13:07:48 +0200 Subject: Fix some typos in 1.1's changelog and migration sections --- doc/build/changelog/changelog_11.rst | 8 ++++---- doc/build/changelog/migration_11.rst | 28 ++++++++++++++-------------- 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. -- cgit v1.2.1