diff options
| author | Mike Bayer <mike_mp@zzzcomputing.com> | 2021-08-17 15:03:57 -0400 |
|---|---|---|
| committer | mike bayer <mike_mp@zzzcomputing.com> | 2021-08-17 19:15:30 +0000 |
| commit | 29485026e9ea6500ea451b1d4a6f66795a02428d (patch) | |
| tree | 7fc54d5815fbe77158ad99868081a530111aa1a7 /lib/sqlalchemy/dialects/oracle/base.py | |
| parent | a7899c44ba15076df8869f5b40d720ccf09d5273 (diff) | |
| download | sqlalchemy-29485026e9ea6500ea451b1d4a6f66795a02428d.tar.gz | |
send user defined options from the current query
Revised the means by which the
:attr:`_orm.ORMExecuteState.user_defined_options` accessor receives
:class:`_orm.UserDefinedOption` and related option objects from the
context, with particular emphasis on the "selectinload" on the loader
strategy where this previously was not working; other strategies did not
have this problem. The objects that are associated with the current query
being executed, and not that of a query being cached, are now propagated
unconditionally. This essentially separates them out from the "loader
strategy" options which are explicitly associated with the compiled state
of a query and need to be used in relation to the cached query.
The effect of this fix is that a user-defined option, such as those used
by the dogpile.caching example as well as for other recipes such as
defining a "shard id" for the horizontal sharing extension, will be
correctly propagated to eager and lazy loaders regardless of whether
a cached query was ultimately invoked.
Fixes: #6887
Change-Id: Ieaae5b01c85de26ea732ebd625e6e5823a470492
Diffstat (limited to 'lib/sqlalchemy/dialects/oracle/base.py')
0 files changed, 0 insertions, 0 deletions
