| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Repaired a major shortcoming which was identified in the
:ref:`engine_insertmanyvalues` performance optimization feature first
introduced in the 2.0 series. This was a continuation of the change in
2.0.9 which disabled the SQL Server version of the feature due to a
reliance in the ORM on apparent row ordering that is not guaranteed to take
place. The fix applies new logic to all "insertmanyvalues" operations,
which takes effect when a new parameter
:paramref:`_dml.Insert.returning.sort_by_parameter_order` on the
:meth:`_dml.Insert.returning` or :meth:`_dml.UpdateBase.return_defaults`
methods, that through a combination of alternate SQL forms, direct
correspondence of client side parameters, and in some cases downgrading to
running row-at-a-time, will apply sorting to each batch of returned rows
using correspondence to primary key or other unique values in each row
which can be correlated to the input data.
Performance impact is expected to be minimal as nearly all common primary
key scenarios are suitable for parameter-ordered batching to be
achieved for all backends other than SQLite, while "row-at-a-time"
mode operates with a bare minimum of Python overhead compared to the very
heavyweight approaches used in the 1.x series. For SQLite, there is no
difference in performance when "row-at-a-time" mode is used.
It's anticipated that with an efficient "row-at-a-time" INSERT with
RETURNING batching capability, the "insertmanyvalues" feature can be later
be more easily generalized to third party backends that include RETURNING
support but not necessarily easy ways to guarantee a correspondence
with parameter order.
Fixes: #9618
References: #9603
Change-Id: I1d79353f5f19638f752936ba1c35e4dc235a8b7c
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added missing init overload to :class:`_sql.Numeric` to allow
type checkers to properly resolve the type var given the
``asdecimal`` parameter.
this fortunately fixes a glitch in the generate_sql_functions script
also
Fixes: #9391
Change-Id: I9cecc40c52711489e9dbe663f110c3b81c7285e4
|
| |
|
|
|
|
|
|
|
|
| |
Added typing for the built-in generic functions that are available from the
:data:`_sql.func` namespace, which accept a particular set of arguments and
return a particular type, such as for :class:`_sql.count`,
:class:`_sql.current_timestamp`, etc.
Fixes: #9129
Change-Id: I1a2e0dcca3048c77e84dc786843a7df05c457dfa
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
change {opensql} to {printsql} in prints, add missing markers
Change-Id: I07b72e6620bb64e329d6b641afa27631e91c4f16
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improved a fix first made in version 1.4 for :ticket:`8456` which scaled
back the usage of internal "polymorphic adapters", that are used to render
ORM queries when the :paramref:`_orm.Mapper.with_polymorphic` parameter is
used. These adapters, which are very complex and error prone, are now used
only in those cases where an explicit user-supplied subquery is used for
:paramref:`_orm.Mapper.with_polymorphic`, which includes only the use case
of concrete inheritance mappings that use the
:func:`_orm.polymorphic_union` helper, as well as the legacy use case of
using an aliased subquery for joined inheritance mappings, which is not
needed in modern use.
For the most common case of joined inheritance mappings that use the
built-in polymorphic loading scheme, which includes those which make use of
the :paramref:`_orm.Mapper.polymorphic_load` parameter set to ``inline``,
polymorphic adapters are now no longer used. This has both a positive
performance impact on the construction of queries as well as a
substantial simplification of the internal query rendering process.
The specific issue targeted was to allow a :func:`_orm.column_property`
to refer to joined-inheritance classes within a scalar subquery, which now
works as intuitively as is feasible.
ORM context, mapper, strategies now use ORMAdapter in all cases
instead of straight ColumnAdapter; added some more parameters
to ORMAdapter to make this possible. ORMAdapter now includes a
"trace" enumeration that identifies the use path for the
adapter and can aid in debugging.
implement __slots__ for the ExternalTraversal hierarchy up
to ORMAdapter. Within this change, we have to change the
ClauseAdapter.wrap() method, which is only used in one polymorphic
codepath, to use copy.copy() instead of
`__dict__` access (apparently `__reduce_ex__` is implemented for
objects with `__slots__`), and we also remove pickling ability,
which should not be needed for adapters (this might have been needed
for 1.3 and earlier in order for Query to be picklable, but none
of that state is present within Query / select() / etc. anymore).
Fixes: #8168
Change-Id: I3f6593eb02ab5e5964807c53a9fa4894c826d017
|
| |
|
|
|
|
|
|
|
|
|
| |
Create a new test file test_tm_future_annotations_sync.py that's obtained
from test_tm_future_annotations.py by using the new script sync_test_files.
This files includes the ``from __future__ import annotations``
It also turns out we had some bugs in there and we can also support some
additional typing things
Change-Id: Iac005df206d45a55345d9d88d67a80ce799d449f
|
| |
|
|
|
|
|
|
| |
command run is "pyupgrade --py37-plus --keep-runtime-typing --keep-percent-format <files...>"
pyupgrade will change assert_ to assertTrue. That was reverted since assertTrue does not
exists in sqlalchemy fixtures
Change-Id: Ie1ed2675c7b11d893d78e028aad0d1576baebb55
|
| |
|
|
|
| |
Fixes: #8605
Change-Id: I4aec83b9f321462427c3f4ac941c3b272255c088
|
| |
|
|
|
|
| |
I5c7f172e5224fa08d0675160ac919d0b045a26eb
Change-Id: Ieb7971297f959fd635a4627bd93154e28ef0ef2b
|
| |
|
|
|
|
|
|
| |
also fixes issue in format_docs_code which didn't work with
pre-commit for more than one file. will backport
Fixes: #8597
Change-Id: I21b2625514987b1cd90f7c00f06e72e57e257390
|
| |
|
|
| |
Change-Id: Ia41399155ee0ec1b878aebf18967eabe38f5afd1
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
|
| |
Improve format docs script, replace {sql} with {opensql}
Change-Id: Ie1aaa8f3d8ff8f8e89b7b5149a1876d9f8a211ed
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
this so that I can still have
{opensql} and {stop} sections in non-console python.
this isn't the norm but I would prefer if I dont have to
be 100% strict about it
also maintaining {sql} / {stop} being at the start
of a code line. this is more prevalent in 1.4.
Change-Id: Iaf748b7ff1120e21f729c2fd794d9b8a33d83170
|
| |
|
|
| |
Change-Id: I63585eeae0b0bc78109da64520696928dfb3982c
|
| |
|
|
| |
Change-Id: I75cf7143f3ed3bbc09aa8bc18edbce5c8af0f0be
|
| |
|
|
|
|
|
|
| |
Added script to format code in the rst documentation using black.
This is also added to the lint tox job to ensure that the code
in the docs is properly formatted.
Change-Id: I799444f22da153484ca5f095d57755762348da40
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
