From: Kevin Kirsche Date: Wed, 8 Sep 2021 19:14:31 +0000 (-0400) Subject: fix: typos in doc/build/orm (#7003) X-Git-Tag: rel_1_4_24~40 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f53eebf23dc1e2bcbd77ba69139da748609068b1;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git fix: typos in doc/build/orm (#7003) * fix: typos in doc/build/orm * though -> through Change-Id: I785336056497a4ac17f2d494f6d9cf913c12b024 Co-authored-by: Federico Caselli --- diff --git a/doc/build/orm/basic_relationships.rst b/doc/build/orm/basic_relationships.rst index bb790d9914..40b3590b6f 100644 --- a/doc/build/orm/basic_relationships.rst +++ b/doc/build/orm/basic_relationships.rst @@ -655,7 +655,7 @@ that will be passed to ``eval()`` are: .. versionchanged:: 1.3.16 Prior to SQLAlchemy 1.3.16, the main :paramref:`_orm.relationship.argument` - to :func:`_orm.relationship` was also evaluated throught ``eval()`` As of + to :func:`_orm.relationship` was also evaluated through ``eval()`` As of 1.3.16 the string name is resolved from the class resolver directly without supporting custom Python expressions. diff --git a/doc/build/orm/cascades.rst b/doc/build/orm/cascades.rst index 1f438035f6..1a2a7804c2 100644 --- a/doc/build/orm/cascades.rst +++ b/doc/build/orm/cascades.rst @@ -262,7 +262,7 @@ rules it will also delete all related ``Child`` rows. relationships, then the cascade action would continue cascading through all ``Parent`` and ``Child`` objects, loading each ``children`` and ``parents`` collection encountered and deleting everything that's connected. It is - typically not desireable for "delete" cascade to be configured + typically not desirable for "delete" cascade to be configured bidirectionally. .. seealso:: diff --git a/doc/build/orm/extensions/asyncio.rst b/doc/build/orm/extensions/asyncio.rst index f3e89c647a..5c833e4e49 100644 --- a/doc/build/orm/extensions/asyncio.rst +++ b/doc/build/orm/extensions/asyncio.rst @@ -463,7 +463,7 @@ Using asyncio scoped session The usage of :class:`_asyncio.async_scoped_session` is mostly similar to :class:`.scoped_session`. However, since there's no "thread-local" concept in -the asyncio context, the "scopefunc" paramater must be provided to the +the asyncio context, the "scopefunc" parameter must be provided to the constructor:: from asyncio import current_task diff --git a/doc/build/orm/extensions/mypy.rst b/doc/build/orm/extensions/mypy.rst index edd3af7c0a..b710d1f443 100644 --- a/doc/build/orm/extensions/mypy.rst +++ b/doc/build/orm/extensions/mypy.rst @@ -379,7 +379,7 @@ a collection annotation such as ``List`` may be used. It is also fully appropriate to use the string name of the class in the annotation as supported by pep-484, ensuring the class is imported with in the `TYPE_CHECKING block `_ -as approriate:: +as appropriate:: from typing import List, TYPE_CHECKING from .mymodel import Base @@ -548,4 +548,4 @@ This attribute can be conditional within the ``TYPE_CHECKING`` variable:: With the above recipe, the attributes listed in ``_mypy_mapped_attrs`` will be applied with the :class:`_orm.Mapped` typing information so that the ``User`` class will behave as a SQLAlchemy mapped class when used in a -class-bound context. \ No newline at end of file +class-bound context. diff --git a/doc/build/orm/loading_objects.rst b/doc/build/orm/loading_objects.rst index 3075ea9f4e..956ef2f699 100644 --- a/doc/build/orm/loading_objects.rst +++ b/doc/build/orm/loading_objects.rst @@ -8,7 +8,7 @@ ORM mapped objects, but also involves calling forms that deliver individual column or groups of columns as well. For an introduction to querying with the SQLAlchemy ORM, one of the -following tutorials shoud be consulted: +following tutorials should be consulted: * :doc:`/tutorial/index` - for :term:`2.0 style` usage diff --git a/doc/build/orm/session_basics.rst b/doc/build/orm/session_basics.rst index d53b16074e..529f786c1a 100644 --- a/doc/build/orm/session_basics.rst +++ b/doc/build/orm/session_basics.rst @@ -536,7 +536,7 @@ UPDATE and DELETE with arbitrary WHERE clause The sections above on :meth:`_orm.Session.flush` and :meth:`_orm.Session.delete` detail how rows can be inserted, updated and deleted in the database, based on primary key identities that are referred towards by mapped Python -objets in the application. The :class:`_orm.Session` can also emit UPDATE +objects in the application. The :class:`_orm.Session` can also emit UPDATE and DELETE statements with arbitrary WHERE clauses as well, and at the same time refresh locally present objects which match those rows. @@ -617,7 +617,7 @@ values for ``synchronize_session`` are supported: * ``'evaluate'`` - Evaluate the WHERE criteria given in the UPDATE or DELETE statement in Python, to locate matching objects within the :class:`_orm.Session`. This approach does not add any round trips and in - the absense of RETURNING support is more efficient. For UPDATE or DELETE + the absence of RETURNING support is more efficient. For UPDATE or DELETE statements with complex criteria, the ``'evaluate'`` strategy may not be able to evaluate the expression in Python and will raise an error. If this occurs, use the ``'fetch'`` strategy for the operation instead. @@ -817,7 +817,7 @@ automatically (it's currently not possible for a flush to continue after a partial failure). However, the :class:`_orm.Session` goes into a state known as "inactive" at this point, and the calling application must always call the :meth:`_orm.Session.rollback` method explicitly so that the -:class:`_orm.Session` can go back into a useable state (it can also be simply +:class:`_orm.Session` can go back into a usable state (it can also be simply closed and discarded). See the FAQ entry at :ref:`faq_session_rollback` for further discussion. diff --git a/doc/build/orm/session_transaction.rst b/doc/build/orm/session_transaction.rst index bc901762b6..e7401f618f 100644 --- a/doc/build/orm/session_transaction.rst +++ b/doc/build/orm/session_transaction.rst @@ -14,7 +14,7 @@ Managing Transactions The :class:`_orm.Session` tracks the state of a single "virtual" transaction at a time, using an object called -:class:`_orm.SessionTransaction`. This object then makes use of the underyling +:class:`_orm.SessionTransaction`. This object then makes use of the underlying :class:`_engine.Engine` or engines to which the :class:`_orm.Session` object is bound in order to start real connection-level transactions using the :class:`_engine.Connection` object as needed. @@ -59,7 +59,7 @@ or rolled back:: session.commit() # commits # will automatically begin again - result = session.execute(< some select statment >) + result = session.execute(< some select statement >) session.add_all([more_objects, ...]) session.commit() # commits @@ -146,7 +146,7 @@ method:: # commits u1 and u2 Each time :meth:`_orm.Session.begin_nested` is called, a new "BEGIN SAVEPOINT" -command is emitted to the database wih a unique identifier. When +command is emitted to the database with a unique identifier. When :meth:`_orm.SessionTransaction.commit` is called, "RELEASE SAVEPOINT" is emitted on the database, and if instead :meth:`_orm.SessionTransaction.rollback` is called, "ROLLBACK TO SAVEPOINT"