From 1f6a129d80453e274d1e14631f065b1afaa37b96 Mon Sep 17 00:00:00 2001 From: Andreas Deininger Date: Mon, 11 Mar 2024 22:40:14 +0100 Subject: [PATCH] Fixing typos (#11105) --- doc/build/changelog/changelog_20.rst | 2 +- doc/build/changelog/whatsnew_20.rst | 2 +- doc/build/core/custom_types.rst | 2 +- doc/build/core/operators.rst | 2 +- doc/build/index.rst | 2 +- doc/build/intro.rst | 2 +- doc/build/orm/collection_api.rst | 2 +- doc/build/orm/composites.rst | 2 +- doc/build/orm/dataclasses.rst | 2 +- doc/build/orm/declarative_tables.rst | 4 ++-- doc/build/orm/persistence_techniques.rst | 4 ++-- doc/build/orm/queryguide/columns.rst | 2 +- doc/build/orm/queryguide/dml.rst | 6 +++--- doc/build/tutorial/data_update.rst | 2 +- doc/build/tutorial/orm_data_manipulation.rst | 2 +- 15 files changed, 19 insertions(+), 19 deletions(-) diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst index 8e3ee935b9..8dc3bb9c76 100644 --- a/doc/build/changelog/changelog_20.rst +++ b/doc/build/changelog/changelog_20.rst @@ -27,7 +27,7 @@ value the DBAPI offers for any kind of statement will be available using the :attr:`_engine.CursorResult.rowcount` attribute from the :class:`_engine.CursorResult`. This allows the rowcount to be accessed for - statments such as INSERT and SELECT, to the degree supported by the DBAPI + statements such as INSERT and SELECT, to the degree supported by the DBAPI in use. The :ref:`engine_insertmanyvalues` also supports this option and will ensure :attr:`_engine.CursorResult.rowcount` is correctly set for a bulk INSERT of rows when set. diff --git a/doc/build/changelog/whatsnew_20.rst b/doc/build/changelog/whatsnew_20.rst index 66610e26c4..26241d58db 100644 --- a/doc/build/changelog/whatsnew_20.rst +++ b/doc/build/changelog/whatsnew_20.rst @@ -1051,7 +1051,7 @@ implemented by :meth:`_orm.Session.bulk_insert_mappings`, with additional enhancements. This will optimize the batching of rows making use of the new :ref:`fast insertmany ` feature, while also adding support for -heterogenous parameter sets and multiple-table mappings like joined table +heterogeneous parameter sets and multiple-table mappings like joined table inheritance:: >>> users = session.scalars( diff --git a/doc/build/core/custom_types.rst b/doc/build/core/custom_types.rst index f9c0205249..90fc503186 100644 --- a/doc/build/core/custom_types.rst +++ b/doc/build/core/custom_types.rst @@ -173,7 +173,7 @@ Backend-agnostic GUID Type .. note:: Since version 2.0 the built-in :class:`_types.Uuid` type that behaves similarly should be preferred. This example is presented - just as an example of a type decorator that recieves and returns + just as an example of a type decorator that receives and returns python objects. Receives and returns Python uuid() objects. diff --git a/doc/build/core/operators.rst b/doc/build/core/operators.rst index 0450aab03e..35c25fe75c 100644 --- a/doc/build/core/operators.rst +++ b/doc/build/core/operators.rst @@ -303,7 +303,7 @@ databases support: using the :meth:`_sql.ColumnOperators.__eq__` overloaded operator, i.e. ``==``, in conjunction with the ``None`` or :func:`_sql.null` value. In this way, there's typically not a need to use :meth:`_sql.ColumnOperators.is_` - explicitly, paricularly when used with a dynamic value:: + explicitly, particularly when used with a dynamic value:: >>> a = None >>> print(column("x") == a) diff --git a/doc/build/index.rst b/doc/build/index.rst index 8814427588..43e902fa3f 100644 --- a/doc/build/index.rst +++ b/doc/build/index.rst @@ -177,7 +177,7 @@ SQLAlchemy Documentation * :doc:`Frequently Asked Questions ` - A collection of common problems and solutions * :doc:`Glossary ` - Terms used in SQLAlchemy's documentation - * :doc:`Error Message Guide ` - Explainations of many SQLAlchemy Errors + * :doc:`Error Message Guide ` - Explanations of many SQLAlchemy Errors * :doc:`Complete table of of contents ` * :ref:`Index ` diff --git a/doc/build/intro.rst b/doc/build/intro.rst index 162604b24c..ee93cc3295 100644 --- a/doc/build/intro.rst +++ b/doc/build/intro.rst @@ -142,7 +142,7 @@ Installing with AsyncIO Support SQLAlchemy's ``asyncio`` support depends upon the `greenlet `_ project. This dependency -is not inclued by default. To install with asyncio support, run this command: +is not included by default. To install with asyncio support, run this command: .. sourcecode:: text diff --git a/doc/build/orm/collection_api.rst b/doc/build/orm/collection_api.rst index b256af92a1..07e4a4ce88 100644 --- a/doc/build/orm/collection_api.rst +++ b/doc/build/orm/collection_api.rst @@ -129,7 +129,7 @@ Python code, as well as in a few special cases, the collection class for a In the absence of :paramref:`_orm.relationship.collection_class` or :class:`_orm.Mapped`, the default collection type is ``list``. -Beyond ``list`` and ``set`` builtins, there is also support for two varities of +Beyond ``list`` and ``set`` builtins, there is also support for two varieties of dictionary, described below at :ref:`orm_dictionary_collection`. There is also support for any arbitrary mutable sequence type can be set up as the target collection, with some additional configuration steps; this is described in the diff --git a/doc/build/orm/composites.rst b/doc/build/orm/composites.rst index 2e625509e0..b0ddb9ea48 100644 --- a/doc/build/orm/composites.rst +++ b/doc/build/orm/composites.rst @@ -182,7 +182,7 @@ Other mapping forms for composites The :func:`_orm.composite` construct may be passed the relevant columns using a :func:`_orm.mapped_column` construct, a :class:`_schema.Column`, or the string name of an existing mapped column. The following examples -illustrate an equvalent mapping as that of the main section above. +illustrate an equivalent mapping as that of the main section above. * Map columns directly, then pass to composite diff --git a/doc/build/orm/dataclasses.rst b/doc/build/orm/dataclasses.rst index 1fa37938ec..2c45a4d019 100644 --- a/doc/build/orm/dataclasses.rst +++ b/doc/build/orm/dataclasses.rst @@ -424,7 +424,7 @@ scalar object references may make use of The above mapping will generate an empty list for ``Parent.children`` when a new ``Parent()`` object is constructed without passing ``children``, and similarly a ``None`` value for ``Child.parent`` when a new ``Child()`` object -is constructed without passsing ``parent``. +is constructed without passing ``parent``. While the :paramref:`_orm.relationship.default_factory` can be automatically derived from the given collection class of the :func:`_orm.relationship` diff --git a/doc/build/orm/declarative_tables.rst b/doc/build/orm/declarative_tables.rst index d2ed13841f..b2c91981b3 100644 --- a/doc/build/orm/declarative_tables.rst +++ b/doc/build/orm/declarative_tables.rst @@ -237,7 +237,7 @@ The two qualities that :func:`_orm.mapped_column` derives from the In the absence of **both** of these parameters, the presence of ``typing.Optional[]`` within the :class:`_orm.Mapped` type annotation will be used to determine nullability, where ``typing.Optional[]`` means ``NULL``, - and the absense of ``typing.Optional[]`` means ``NOT NULL``. If there is no + and the absence of ``typing.Optional[]`` means ``NOT NULL``. If there is no ``Mapped[]`` annotation present at all, and there is no :paramref:`_orm.mapped_column.nullable` or :paramref:`_orm.mapped_column.primary_key` parameter, then SQLAlchemy's usual @@ -539,7 +539,7 @@ specific to each attribute:: When using ``Annotated`` types in this way, the configuration of the type may also be affected on a per-attribute basis. For the types in the above -example that feature explcit use of :paramref:`_orm.mapped_column.nullable`, +example that feature explicit use of :paramref:`_orm.mapped_column.nullable`, we can apply the ``Optional[]`` generic modifier to any of our types so that the field is optional or not at the Python level, which will be independent of the ``NULL`` / ``NOT NULL`` setting that takes place in the database:: diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst index 69fad33b22..da914e5c93 100644 --- a/doc/build/orm/persistence_techniques.rst +++ b/doc/build/orm/persistence_techniques.rst @@ -332,7 +332,7 @@ Case 2: Table includes trigger-generated values which are not compatible with RE The ``"auto"`` setting of :paramref:`_orm.Mapper.eager_defaults` means that a backend that supports RETURNING will usually make use of RETURNING with -INSERT statements in order to retreive newly generated default values. +INSERT statements in order to retrieve newly generated default values. However there are limitations of server-generated values that are generated using triggers, such that RETURNING can't be used: @@ -367,7 +367,7 @@ this looks like:: On SQL Server with the pyodbc driver, an INSERT for the above table will not use RETURNING and will use the SQL Server ``scope_identity()`` function -to retreive the newly generated primary key value: +to retrieve the newly generated primary key value: .. sourcecode:: sql diff --git a/doc/build/orm/queryguide/columns.rst b/doc/build/orm/queryguide/columns.rst index 93d0919ba5..ace6a63f4c 100644 --- a/doc/build/orm/queryguide/columns.rst +++ b/doc/build/orm/queryguide/columns.rst @@ -595,7 +595,7 @@ by default not loadable:: ... sqlalchemy.exc.InvalidRequestError: 'Book.summary' is not available due to raiseload=True -Only by overridding their behavior at query time, typically using +Only by overriding their behavior at query time, typically using :func:`_orm.undefer` or :func:`_orm.undefer_group`, or less commonly :func:`_orm.defer`, may the attributes be loaded. The example below applies ``undefer('*')`` to undefer all attributes, also making use of diff --git a/doc/build/orm/queryguide/dml.rst b/doc/build/orm/queryguide/dml.rst index a2c10c1bb3..a4b00da725 100644 --- a/doc/build/orm/queryguide/dml.rst +++ b/doc/build/orm/queryguide/dml.rst @@ -204,7 +204,7 @@ the operation will INSERT one row at a time:: .. _orm_queryguide_insert_heterogeneous_params: -Using Heterogenous Parameter Dictionaries +Using Heterogeneous Parameter Dictionaries ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. Setup code, not for display @@ -215,7 +215,7 @@ Using Heterogenous Parameter Dictionaries BEGIN (implicit)... The ORM bulk insert feature supports lists of parameter dictionaries that are -"heterogenous", which basically means "individual dictionaries can have different +"heterogeneous", which basically means "individual dictionaries can have different keys". When this condition is detected, the ORM will break up the parameter dictionaries into groups corresponding to each set of keys and batch accordingly into separate INSERT statements:: @@ -552,7 +552,7 @@ are not present: or other multi-table mappings are not supported, since that would require multiple INSERT statements. -* :ref:`Heterogenous parameter sets ` +* :ref:`Heterogeneous parameter sets ` are not supported - each element in the VALUES set must have the same columns. diff --git a/doc/build/tutorial/data_update.rst b/doc/build/tutorial/data_update.rst index 48cf5c058a..e32b6676c7 100644 --- a/doc/build/tutorial/data_update.rst +++ b/doc/build/tutorial/data_update.rst @@ -280,7 +280,7 @@ Facts about :attr:`_engine.CursorResult.rowcount`: * :attr:`_engine.CursorResult.rowcount` is not necessarily available for an UPDATE or DELETE statement that uses RETURNING, or for one that uses an - :ref:`executemany ` execution. The availablility + :ref:`executemany ` execution. The availability depends on the DBAPI module in use. * In any case where the DBAPI does not determine the rowcount for some type diff --git a/doc/build/tutorial/orm_data_manipulation.rst b/doc/build/tutorial/orm_data_manipulation.rst index b4beae0e07..9329d20524 100644 --- a/doc/build/tutorial/orm_data_manipulation.rst +++ b/doc/build/tutorial/orm_data_manipulation.rst @@ -157,7 +157,7 @@ Another effect of the INSERT that occurred was that the ORM has retrieved the new primary key identifiers for each new object; internally it normally uses the same :attr:`_engine.CursorResult.inserted_primary_key` accessor we introduced previously. The ``squidward`` and ``krabs`` objects now have these new -primary key identifiers associated with them and we can view them by acesssing +primary key identifiers associated with them and we can view them by accessing the ``id`` attribute:: >>> squidward.id -- 2.47.2