Fixed regression where using ORM update() with synchronize_session='fetch'
would fail due to the use of evaluators that are now used to determine the
- in-Python value for expressions in the the SET clause when refreshing
+ in-Python value for expressions in the SET clause when refreshing
objects; if the evaluators make use of math operators against non-numeric
values such as PostgreSQL JSONB, the non-evaluable condition would fail to
be detected correctly. The evaluator now limits the use of math mutation
:class:`_result.Result` class and implemented it for the filtered result
implementations that are used by the ORM, so that it is possible to call
the :meth:`_engine.CursorResult.close` method on the underlying
- :class:`_engine.CursorResult` when the the ``yield_per`` execution option
+ :class:`_engine.CursorResult` when the ``yield_per`` execution option
is in use to close a server side cursor before remaining ORM results have
been fetched. This was again already available for Core result sets but the
change makes it available for 2.0 style ORM results as well.
cascade operation actually takes place. The new behavior can be
established as always by setting the flag to ``False`` on a specific
:func:`_orm.relationship`, or more generally can be set up across the board
- by setting the the :paramref:`_orm.Session.future` flag to True.
+ by setting the :paramref:`_orm.Session.future` flag to True.
.. seealso::
Added an error message when a :func:`_orm.relationship` is mapped against
an abstract container type, such as ``Mapped[Sequence[B]]``, without
providing the :paramref:`_orm.relationship.container_class` parameter which
- is necessary when the type is abstract. Previously the the abstract
+ is necessary when the type is abstract. Previously the abstract
container would attempt to be instantiated at a later step and fail.
In addition to using a pure mixin, most of the techniques in this
section can also be applied to the base class directly, for patterns that
should apply to all classes derived from a particular base. The example
-below illustrates some of the the previous section's example in terms of the
+below illustrates some of the previous section's example in terms of the
``Base`` class::
from sqlalchemy import ForeignKey
FROM user_account JOIN address ON user_account.id = address.user_id
-The other is the the :meth:`_sql.Select.join` method, which indicates only the
+The other is the :meth:`_sql.Select.join` method, which indicates only the
right side of the JOIN, the left hand-side is inferred::
>>> print(select(user_table.c.name, address_table.c.email_address).join(address_table))
)
# The last inserted primary key should be 2 here
- # it is taking the result from the the exotic fixture
+ # it is taking the result from the exotic fixture
eq_(result.inserted_primary_key, (2,))
eq_(
"FROM a WHERE a.id IN (__[POSTCOMPILE_id_1]) ORDER BY a.id",
[{"id_1": [1, 3]}],
),
- # in the very unlikely case that the the FK col on parent is
+ # in the very unlikely case that the FK col on parent is
# deferred, we degrade to the JOIN version so that we don't need to
# emit either for each parent object individually, or as a second
# query for them.
CompiledSQL(
"SELECT a.id AS a_id, a.q AS a_q FROM a ORDER BY a.id", [{}]
),
- # in the very unlikely case that the the FK col on parent is
+ # in the very unlikely case that the FK col on parent is
# deferred, we degrade to the JOIN version so that we don't need to
# emit either for each parent object individually, or as a second
# query for them.
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
