summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql
Commit message (Collapse)AuthorAgeFilesLines
* Replace c extension with cython versions.workflow_test_cythonFederico Caselli2021-12-171-1/+1
| | | | | | | | | | | | | | | Re-implement c version immutabledict / processors / resultproxy / utils with cython. Performance is in general in par or better than the c version Added a collection module that has cython version of OrderedSet and IdentitySet Added a new test/perf file to compare the implementations. Run ``python test/perf/compiled_extensions.py all`` to execute the comparison test. See results here: https://docs.google.com/document/d/1nOcDGojHRtXEkuy4vNXcW_XOJd9gqKhSeALGG3kYr6A/edit?usp=sharing Fixes: #7256 Change-Id: I2930ef1894b5048210384728118e586e813f6a76 Signed-off-by: Federico Caselli <cfederico87@gmail.com>
* Merge "Removals: strings for join(), loader_options()." into mainmike bayer2021-12-101-25/+2
|\
| * Removals: strings for join(), loader_options().Mike Bayer2021-12-081-25/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * The :meth:`_orm.Query.join` method no longer accepts strings for relationship names; the long-documented approach of using ``Class.attrname`` for join targets is now standard. * Loader options no longer accept strings for attribute names. The long-documented approach of using ``Class.attrname`` for loader option targets is now standard. It is hoped that a subsequent commit can refactor loader options to no longer need "UnboundLoad" for most cases. Change-Id: If4629882c40523dccbf4459256bf540fb468b618 References: #6986
* | Fix typo in docstringLele Gaifax2021-12-091-1/+1
|/
* Merge "Warn when caching is disabled / document" into mainmike bayer2021-12-078-11/+147
|\
| * Warn when caching is disabled / documentMike Bayer2021-12-068-11/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds new warnings for all elements that don't indicate their caching behavior, including user-defined ClauseElement subclasses and third party dialects. it additionally adds new documentation to discuss an apparent performance degradation in 1.4 when caching is disabled as a result in the significant expense incurred by ORM lazy loaders, which in 1.3 used BakedQuery so were actually cached. As a result of adding the warnings, a fair degree of lesser used SQL expression objects identified that they did not define caching behavior so would have been producing ``[no key]``, including PostgreSQL constructs ``hstore`` and ``array``. These have been amended to use inherit cache where appropriate. "on conflict" constructs in PostgreSQL, MySQL, SQLite still explicitly don't generate a cache key at this time. The change also adds a test for all constructs via assert_compile() to assert they will not generate cache warnings. Fixes: #7394 Change-Id: I85958affbb99bfad0f5efa21bc8f2a95e7e46981
* | fix typo in exists documentationFederico Caselli2021-12-051-1/+1
| | | | | | | | Change-Id: I44d8d6ee4816052a8dda64c00905b17b7ad8698e
* | The where method of exists now accepts multiple cluase.Federico Caselli2021-12-041-2/+8
|/ | | | | | | | | Support multiple clause elements in the :meth:`_sql.Exists.where` method, unifying the api with the on presented by a normal :func:`_sql.select` construct. Fixes: #7386 Change-Id: I5df20478008cd5167053d357cbfad8a641c62b44
* Removals: MetaData.bind, Table.bind, all other .bindMike Bayer2021-12-028-595/+52
| | | | | Change-Id: I1ef2eb2018f4b68825fe40a2a8d99084cf217b35 References: #7257
* provide connectionfairy on initializeMike Bayer2021-11-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is so that dialect methods that are called within init can assume the same argument structure as when they are called in other places; we can nail down the type of object as well. This change seems to mostly impact the isolation level routines in the dialects, as these are called during initialize() as well as on established connections. these methods can now assume a non-proxied DBAPI connection object in all cases, as it is commonly required that attributes like ".autocommit" are set on the object which don't work well in a proxied situation. Other changes: * adds an interface for the "connectionfairy" concept called PoolProxiedConnection. * Removes ``Connectable`` superclass of Connection. ``Connectable`` was originally meant to provide for the "method which accepts connection or engine" theme. As this pattern is greatly reduced in 2.0 and Engine no longer extends from it, the ``Connectable`` superclass doesnt serve any real purpose. Leading from that, to set this in I also applied pep 484 annotations to the Dialect base, and then in the interests of seeing some of the typing information show up in my IDE did a little bit for Engine, Connection and others. I hope that it's feasible that we can add annotations to specific classes and attributes ahead of when we actually try to mass-populate the whole library. This was the original spirit of pep-484 that we can apply annotations gradually. I do of course want to try to do a mass-populate although i think even in that case we will end up doing a lot of manual work anyway (in particular for the changes here which are distinct from what the stubs have). Fixes: #7122 Change-Id: I5dd7fbff8a7ae520a81c165091af12a6a68826db
* Added support for ``psycopg`` dialect.Federico Caselli2021-11-261-14/+28
| | | | | | | Both sync and async versions are supported. Fixes: #6842 Change-Id: I57751c5028acebfc6f9c43572562405453a2f2a4
* Merge "propose emulated setinputsizes embedded in the compiler" into mainmike bayer2021-11-252-53/+77
|\
| * propose emulated setinputsizes embedded in the compilerMike Bayer2021-11-232-53/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new system so that PostgreSQL and other dialects have a reliable way to add casts to bound parameters in SQL statements, replacing previous use of setinputsizes() for PG dialects. rationale: 1. psycopg3 will be using the same SQLAlchemy-side "setinputsizes" as asyncpg, so we will be seeing a lot more of this 2. the full rendering that SQLAlchemy's compilation is performing is in the engine log as well as error messages. Without this, we introduce three levels of SQL rendering, the compiler, the hidden "setinputsizes" in SQLAlchemy, and then whatever the DBAPI driver does. With this new approach, users reporting bugs etc. will be less confused that there are as many as two separate layers of "hidden rendering"; SQLAlchemy's rendering is again fully transparent 3. calling upon a setinputsizes() method for every statement execution is expensive. this way, the work is done behind the caching layer 4. for "fast insertmany()", I also want there to be a fast approach towards setinputsizes. As it was, we were going to be taking a SQL INSERT with thousands of bound parameter placeholders and running a whole second pass on it to apply typecasts. this way, we will at least be able to build the SQL string once without a huge second pass over the whole string 5. psycopg2 can use this same system for its ARRAY casts 6. the general need for PostgreSQL to have lots of type casts is now mostly in the base PostgreSQL dialect and works independently of a DBAPI being present. dependence on DBAPI symbols that aren't complete / consistent / hashable is removed I was originally going to try to build this into bind_expression(), but it was revealed this worked poorly with custom bind_expression() as well as empty sets. the current impl also doesn't need to run a second expression pass over the POSTCOMPILE sections, which came out better than I originally thought it would. Change-Id: I363e6d593d059add7bcc6d1f6c3f91dd2e683c0c
* | Clean up most py3k compatFederico Caselli2021-11-2417-177/+121
|/ | | | Change-Id: I8172fdcc3103ff92aa049827728484c8779af6b7
* Support lightweight compiler column elements w/ slotsMike Bayer2021-11-226-93/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the _CompileLabel class included ``__slots__`` but these weren't used as the superclasses included slots. Create a ``__slots__`` superclass for ``ClauseElement``, creating a new class of compilable SQL elements that don't include heavier features like caching, annotations and cloning, which are meant to be used only in an ad-hoc compiler fashion. Create new ``CompilerColumnElement`` from that which serves in column-oriented contexts, but similarly does not include any expression operator support as it is intended to be used only to generate a string. Apply this to both ``_CompileLabel`` as well as PostgreSQL ``_ColonCast``, which does not actually subclass ``ColumnElement`` as this class has memoized attributes that aren't worth changing, and does not include SQL operator capabilities as these are not needed for these compiler-only objects. this allows us to more inexpensively add new ad-hoc labels / casts etc. at compile time, as we will be seeking to expand out the typecasts that are needed for PostgreSQL dialects in a subsequent patch. Change-Id: I52973ae3295cb6e2eb0d7adc816c678a626643ed
* Remove object in class definitionFederico Caselli2021-11-2218-49/+49
| | | | | References: #4600 Change-Id: I2a62ddfe00bc562720f0eae700a497495d7a987a
* Merge "generalize cache_ok to UserDefinedType" into mainmike bayer2021-11-191-58/+191
|\
| * generalize cache_ok to UserDefinedTypeMike Bayer2021-11-171-58/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended the ``cache_ok`` flag and corresponding warning message if this flag is not defined, a behavior first established for :class:`.TypeDecorator` as part of :ticket:`6436`, to also take place for :class:`.UserDefinedType`, by generalizing the flag and associated caching logic to a new common base for these two types, :class:`.ExternalType`. The change means any current :class:`.UserDefinedType` will now cause SQL statement caching to no longer take place for statements which make use of the datatype, along with a warning being emitted, unless the class defines the :attr:`.UserDefinedType.cache_ok` flag as True. If the datatype cannot form a deterministic, hashable cache key derived from its arguments, it may return False which will continue to keep caching disabled but will suppress the warning. In particular, custom datatypes currently used in packages such as SQLAlchemy-utils will need to implement this flag. The issue was observed as a result of a SQLAlchemy-utils datatype that is not currently cacheable. Fixes: #7319 Change-Id: Ie0b5d4587df87bfe66d2fe7cd4585c3882584575
* | Merge "remove "native decimal" warning" into mainmike bayer2021-11-181-10/+0
|\ \
| * | remove "native decimal" warningMike Bayer2021-11-171-10/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed the warning that emits from the :class:`_types.Numeric` type about DBAPIs not supporting Decimal values natively. This warning was oriented towards SQLite, which does not have any real way without additional extensions or workarounds of handling precision numeric values more than 15 significant digits as it only uses floating point math to represent numbers. As this is a known and documented limitation in SQLite itself, and not a quirk of the pysqlite driver, there's no need for SQLAlchemy to warn for this. The change does not otherwise modify how precision numerics are handled. Values can continue to be handled as ``Decimal()`` or ``float()`` as configured with the :class:`_types.Numeric`, :class:`_types.Float` , and related datatypes, just without the ability to maintain precision beyond 15 significant digits when using SQLite, unless alternate representations such as strings are used. Fixes: #7299 Change-Id: Ic570f8107177dec3ddbe94c7b43f40057b03276a
* | Merge "Add new sections regarding schemas and reflection" into mainmike bayer2021-11-182-3/+3
|\ \ | |/ |/|
| * Add new sections regarding schemas and reflectionjonathan vanasco2021-11-172-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * add a new section to reflection.rst `Schemas and Reflection`. * this contains some text from the ticket * migrate some text from `Specifying the Schema Name` to new section * migrate some text from PostgreSQL dialect to new section * target text is made more generic * cross-reference the postgres and new sections to one another, to avoid duplication of docs * update some docs 'meta' to 'metadata_obj' Fixes: #4387 Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: I2b08672753fb2575d30ada07ead77587468fdade
* | Add Non linear CTE supportEric Masseran2021-11-161-29/+155
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Compound select" methods like :meth:`_sql.Select.union`, :meth:`_sql.Select.intersect_all` etc. now accept ``*other`` as an argument rather than ``other`` to allow for multiple additional SELECTs to be compounded with the parent statement at once. In particular, the change as applied to :meth:`_sql.CTE.union` and :meth:`_sql.CTE.union_all` now allow for a so-called "non-linear CTE" to be created with the :class:`_sql.CTE` construct, whereas previously there was no way to have more than two CTE sub-elements in a UNION together while still correctly calling upon the CTE in recursive fashion. Pull request courtesy Eric Masseran. Allow: ```sql WITH RECURSIVE nodes(x) AS ( SELECT 59 UNION SELECT aa FROM edge JOIN nodes ON bb=x UNION SELECT bb FROM edge JOIN nodes ON aa=x ) SELECT x FROM nodes; ``` Based on @zzzeek suggestion: https://github.com/sqlalchemy/sqlalchemy/pull/7133#issuecomment-933882348 Fixes: #7259 Closes: #7260 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7260 Pull-request-sha: 2565a5fd4b1940e92125e53aeaa731cc682f49bb Change-Id: I685c8379762b5fb6ab4107ff8f4d8a4de70c0ca6
* Merge "removals: all unicode encoding / decoding" into mainmike bayer2021-11-112-282/+19
|\
| * removals: all unicode encoding / decodingMike Bayer2021-11-102-282/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed here includes: * convert_unicode parameters * encoding create_engine() parameter * description encoding support * "non-unicode fallback" modes under Python 2 * String symbols regarding Python 2 non-unicode fallbacks * any concept of DBAPIs that don't accept unicode statements, unicode bound parameters, or that return bytes for strings anywhere except an explicit Binary / BLOB type * unicode processors in Python / C Risk factors: * Whether all DBAPIs do in fact return Unicode objects for all entries in cursor.description now * There was logic for mysql-connector trying to determine description encoding. A quick test shows Unicode coming back but it's not clear if there are still edge cases where they return bytes. if so, these are bugs in that driver, and at most we would only work around it in the mysql-connector DBAPI itself (but we won't do that either). * It seems like Oracle 8 was not expecting unicode bound parameters. I'm assuming this was all Python 2 stuff and does not apply for modern cx_Oracle under Python 3. * third party dialects relying upon built in unicode encoding/decoding but it's hard to imagine any non-SQLAlchemy database driver not dealing exclusively in Python unicode strings in Python 3 Change-Id: I97d762ef6d4dd836487b714d57d8136d0310f28a References: #7257
* | Merge "set within_columns_clause=False for all sub-elements of select()" ↵mike bayer2021-11-091-0/+3
|\ \ | | | | | | | | | into main
| * | set within_columns_clause=False for all sub-elements of select()Mike Bayer2021-11-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where using the feature of using a string label for ordering or grouping described at :ref:`tutorial_order_by_label` would fail to function correctly if used on a :class:`.CTE` construct, when the CTE were embedded inside of an enclosing :class:`_sql.Select` statement that itself was set up as a scalar subquery. Fixes: #7269 Change-Id: Ied6048a1c9a622374a418230c8cfedafa8d3f87e
* | | Merge "change the POSTCOMPILE/ SCHEMA symbols to not conflict w mssql ↵mike bayer2021-11-091-6/+6
|\ \ \ | |_|/ |/| | | | | quoting" into main
| * | change the POSTCOMPILE/ SCHEMA symbols to not conflict w mssql quotingMike Bayer2021-11-091-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjusted the compiler's generation of "post compile" symbols including those used for "expanding IN" as well as for the "schema translate map" to not be based directly on plain bracketed strings with underscores, as this conflicts directly with SQL Server's quoting format of also using brackets, which produces false matches when the compiler replaces "post compile" and "schema translate" symbols. The issue created easy to reproduce examples both with the :meth:`.Inspector.get_schema_names` method when used in conjunction with the :paramref:`_engine.Connection.execution_options.schema_translate_map` feature, as well in the unlikely case that a symbol overlapping with the internal name "POSTCOMPILE" would be used with a feature like "expanding in". Fixes: #7300 Change-Id: I6255c850b140522a4aba95085216d0bca18ce230
* | | Merge "Fixes: #7295" into mainmike bayer2021-11-091-8/+8
|\ \ \ | |_|/ |/| |
| * | Fixes: #7295jonathan vanasco2021-11-061-8/+8
| | | | | | | | | | | | | | | | | | Fixed issue in ``Table``` object where: param:`implicit_returning` was not compatible with: param:`extend_existing`. Change-Id: I16f4ab585d82f5691a3fed9eba04b84730a8a59e
* | | revert mis-commit from aa026c302c6b188a7e28508f9ecb603809b9e03fMike Bayer2021-11-091-2/+0
| | | | | | | | | | | | | | | | | | | | | A scratch line from #7269 was inadvertently committed here. this needs to be in its own commit w/ tests. Change-Id: I62796e18b05bbbd3b6225e9f27e1e63ab98cf24c
* | | De-emphasize notion of "default driver" (DBAPI)Gord Thompson2021-11-091-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | Fixes: #6960 Even though a default driver still exists for each dialect, remove most usages of `dialect://` to encourage users to explicitly specify `dialect+driver://` Change-Id: I0ad42167582df509138fca64996bbb53e379b1af
* | Merge "fully implement future engine and remove legacy" into mainmike bayer2021-11-0710-150/+107
|\ \
| * | fully implement future engine and remove legacyMike Bayer2021-11-0710-150/+107
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The major action here is to lift and move future.Connection and future.Engine fully into sqlalchemy.engine.base. This removes lots of engine concepts, including: * autocommit * Connection running without a transaction, autobegin is now present in all cases * most "autorollback" is obsolete * Core-level subtransactions (i.e. MarkerTransaction) * "branched" connections, copies of connections * execution_options() returns self, not a new connection * old argument formats, distill_params(), simplifies calling scheme between engine methods * before/after_execute() events (oriented towards compiled constructs) don't emit for exec_driver_sql(). before/after_cursor_execute() is still included for this * old helper methods superseded by context managers, connection.transaction(), engine.transaction() engine.run_callable() * ancient engine-level reflection methods has_table(), table_names() * sqlalchemy.testing.engines.proxying_engine References: #7257 Change-Id: Ib20ed816642d873b84221378a9ec34480e01e82c
* | use tuple expansion if type._is_tuple, test for Sequence if no typeMike Bayer2021-11-052-7/+19
|/ | | | | | | | | | | | | | | | | | | Fixed regression where the row objects returned for ORM queries, which are now the normal :class:`_sql.Row` objects, would not be interpreted by the :meth:`_sql.ColumnOperators.in_` operator as tuple values to be broken out into individual bound parameters, and would instead pass them as single values to the driver leading to failures. The change to the "expanding IN" system now accommodates for the expression already being of type :class:`.TupleType` and treats values accordingly if so. In the uncommon case of using "tuple-in" with an untyped statement such as a textual statement with no typing information, a tuple value is detected for values that implement ``collections.abc.Sequence``, but that are not ``str`` or ``bytes``, as always when testing for ``Sequence``. Added :class:`.TupleType` to the top level ``sqlalchemy`` import namespace. Fixes: #7292 Change-Id: I8286387e3b3c3752b3bd4ae3560d4f31172acc22
* use ExpressionElementRole for case targets in case()Mike Bayer2021-11-031-22/+12
| | | | | | | | | | | | | | Fixed regression where the :func:`_sql.text` construct would no longer be accepted as a target case in the "whens" list within a :func:`_sql.case` construct. The regression appears related to an attempt to guard against some forms of literal values that were considered to be ambiguous when passed here; however, there's no reason the target cases shouldn't be interpreted as open-ended SQL expressions just like anywhere else, and a literal string or tuple will be converted to a bound parameter as would be the case elsewhere. Fixes: #7287 Change-Id: I75478adfa115f3292cb1362cc5b2fdf152b0ed6f
* add missing info from groupby documentationFederico Caselli2021-11-031-0/+2
| | | | | Change-Id: Icfaf242353c23a579fe79f9d72500a08d90fcb77 Signed-off-by: Federico Caselli <cfederico87@gmail.com>
* First round of removal of python 2Federico Caselli2021-11-015-65/+10
| | | | | References: #4600 Change-Id: I61e35bc93fe95610ae75b31c18a3282558cd4ffe
* Revise "literal parameters" FAQ sectionMike Bayer2021-11-011-1/+23
| | | | | | | | | | based on feedback in #7271, the emphasis on TypeDecorator as a solution to this problem is not very practical. illustrate a series of quick recipes that are useful for debugging purposes to print out a repr() or simple stringify of a parameter without the need to construct custom dialects or types. Change-Id: I788ce1b5ea01d88dd0a22d03d06f35aabff5e5c8
* Merge "2.0 removals: LegacyRow, connectionless execution, close_with_result" ↵mike bayer2021-10-313-53/+2
|\ | | | | | | into main
| * 2.0 removals: LegacyRow, connectionless execution, close_with_resultMike Bayer2021-10-313-53/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in order to remove LegacyRow / LegacyResult, we have to also lose close_with_result, which connectionless execution relies upon. also includes a new profiles.txt file that's all against py310, as that's what CI is on now. some result counts changed by one function call which was enough to fail the low-count result tests. Replaces Connectable as the common interface between Connection and Engine with EngineEventsTarget. Engine is no longer Connectable. Connection and MockConnection still are. References: #7257 Change-Id: Iad5eba0313836d347e65490349a22b061356896a
* | Remove deprecated dialects and driversFederico Caselli2021-10-311-1/+1
|/ | | | | Fixes: #7258 Change-Id: I3577f665eca04f2632b69bcb090f0a4ec9271db9
* clarify order_by(None) for Core; improve wordingMike Bayer2021-10-291-1/+8
| | | | | | | the order_by(None) convention was documented for orm.Query but not Core select. Change-Id: I0c1ad76c3eefba1cb54b1649cfd09169c17e2bba
* Improve array support on pg8000Federico Caselli2021-10-271-1/+2
| | | | | | References: #6023 Change-Id: I0f6cbc34b3c0bfc0b8c86b3ebe4531e23039b6c0
* add full docs/notes for all TypeEngine/TypeDecorator interactionsMike Bayer2021-10-231-62/+207
| | | | | | | | | | | Added notes to all TypeEngine methods as to which should be overridden by TypeDecorator implementations. Made sure docstrings are present for all TypeDecorator methods as some were missing, and clarified which should be overridden, which should not, as well as what phase each method is called within. Change-Id: Ibd6e7fb0933ad3ca0927d8785d9087e3eddac90e References: #7230
* Merge "Add missing deprecation to ``MetaData.bind`` argument" into mainmike bayer2021-10-201-0/+6
|\
| * Add missing deprecation to ``MetaData.bind`` argumentFederico Caselli2021-10-181-0/+6
| | | | | | | | | | Fixes: #7194 Change-Id: I9dacbb562aa55d9c408a43f8e57050db31dc8bfc
* | remove _resolve_label and related attributesMike Bayer2021-10-202-20/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | these seem to date back to 0.9 and revs like #3148 but none of it seems to be affecting things now, try removing it all and seeing what fails. we've noted that _resolve_label does not appear to be needed, however allow_label_resolve remains relevant both for non-column elements like text() as well as that it is used explicitly by the joined eager loader. Change-Id: Ic8a5d8001ef2a4133360f51a92a6f7b0cc389095
* | process bulk_update_tuples before cache key or compilationMike Bayer2021-10-193-42/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where the use of a :class:`_orm.hybrid_property` attribute or a mapped :func:`_orm.composite` attribute as a key passed to the :meth:`_dml.Update.values` method for an ORM-enabled :class:`_dml.Update` statement, as well as when using it via the legacy :meth:`_orm.Query.update` method, would be processed for incoming ORM/hybrid/composite values within the compilation stage of the UPDATE statement, which meant that in those cases where caching occurred, subsequent invocations of the same statement would no longer receive the correct values. This would include not only hybrids that use the :meth:`_orm.hybrid_property.update_expression` method, but any use of a plain hybrid attribute as well. For composites, the issue instead caused a non-repeatable cache key to be generated, which would break caching and could fill up the statement cache with repeated statements. The :class:`_dml.Update` construct now handles the processing of key/value pairs passed to :meth:`_dml.Update.values` and :meth:`_dml.Update.ordered_values` up front when the construct is first generated, before the cache key has been generated so that the key/value pairs are processed each time, and so that the cache key is generated against the individual column/value pairs that will ultimately be used in the statement. Fixes: #7209 Change-Id: I08f248d1d60ea9690b014c21439b775d951fb9e5
View Lorry Controller Status