Added support for per-session execution options that are merged into all
queries executed within that session. The :class:`_orm.Session`,
:class:`_orm.sessionmaker`, :class:`_orm.scoped_session`,
:class:`_ext.asyncio.AsyncSession`, and
:class:`_ext.asyncio.async_sessionmaker` constructors now accept an
:paramref:`_orm.Session.execution_options` parameter that will be applied
to all explicit query executions (e.g. using :meth:`_orm.Session.execute`,
:meth:`_orm.Session.get`, :meth:`_orm.Session.scalars`) for that session
instance.
Fixes: #12659
Change-Id: I6e19e1567e0c04df32ba1d43baf420fb762f155c
Added method :meth:`_orm.Session.get_one` that behaves like
meth:`_orm.Session.get` but raises an exception instead of returning
None`` if no instance was found with the provided primary key.
Pull request courtesy of Carlos Sousa.
Fixed the :paramref:`_asyncio.AsyncSession.get.execution_options` parameter
which was not being propagated to the underlying :class:`_orm.Session` and
was instead being ignored.
Fixes#10292Closes: #10376
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/10376
Pull-request-sha: 70e4505e93
Change-Id: I78eb9816c26446757b6c6c171df2e400777a3d36
in particular it looks like CI was not picking up on the
"git diff" oriented commands, which were failing to run due
to pathing issues. As we were setting cwd for black/zimports
relative to sqlalchemy library, and tox installs it in
the venv, black/zimports would fail to run from tox, and
since these are subprocess.run we didn't pick up the
failure.
This overall locks down how zimports/black are run
so that we are definitely from the source root, by using
the location of tools/ to determine the root.
Fixes: #8892
Change-Id: I7c54b747edd5a80e0c699b8456febf66d8b62375
nothing happened moving from 22.3 to 22.8. a full run of pre-commit
found some little things in the generate_proxy_methods script.
Change-Id: Ie6b4235b87bbfcb252759c0afb133ab8d0cf51db
after some experimentation it seems mypy is more amenable
to the generic types being fully integrated rather than
having separate spin-off types. so key structures
like Result, Row, Select become generic. For DML
Insert, Update, Delete, these are spun into type-specific
subclasses ReturningInsert, ReturningUpdate, ReturningDelete,
which is fine since the "row-ness" of these constructs
doesn't happen until returning() is called in any case.
a Tuple based model is then integrated so that these
objects can carry along information about their return
types. Overloads at the .execute() level carry through
the Tuple from the invoked object to the result.
To suit the issue of AliasedClass generating attributes
that are dynamic, experimented with a custom subclass
AsAliased, but then just settled on having aliased()
lie to the type checker and return `Type[_O]`, essentially.
will need some type-related accessors for with_polymorphic()
also.
Additionally, identified an issue in Update when used
"mysql style" against a join(), it basically doesn't work
if asked to UPDATE two tables on the same column name.
added an error message to the specific condition where
it happens with a very non-specific error message that we
hit a thing we can't do right now, suggest multi-table
update as a possible cause.
Change-Id: I5eff7eefe1d6166ee74160b2785c5e6a81fa8b95
Also adds some fixes to annotation-based mapping
that have come up, as well as starts to add more
pep-484 test cases
Change-Id: Ia722bbbc7967a11b23b66c8084eb61df9d233fee
our decorator thing generates code in any case,
so point it at the file itself to generate real code
for the blocks rather than doing things dynamically.
this will allow typing tools to have no problem
whatsoever and we also reduce import time overhead.
file size will be a lot bigger though, shrugs.
syntax / dupe method / etc. checking will be accomplished
by our existing linting / typing / formatting tools.
As we are also using "from __future__ import annotations",
we also no longer have to apply quotes to generated
annotations.
Change-Id: I20962cb65bda63ff0fb67357ab346e9b1ef4f108
Mike Bayer