.. 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.
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::
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
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 <https://www.python.org/dev/peps/pep-0484/#runtime-or-type-checking>`_
-as approriate::
+as appropriate::
from typing import List, TYPE_CHECKING
from .mymodel import Base
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.
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
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.
* ``'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.
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.
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.
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
# 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"
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
