summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql
Commit message (Collapse)AuthorAgeFilesLines
* fix ORM support for column-named bindparam() in crud .values()Mike Bayer2023-01-111-2/+5
| | | | | | | | | | | | | | | | | | | | | | | Fixed bug / regression where using :func:`.bindparam()` with the same name as a column in the :meth:`.Update.values` method of :class:`.Update`, as well as the :meth:`.Insert.values` method of :class:`.Insert` in 2.0 only, would in some cases silently fail to honor the SQL expression in which the parameter were presented, replacing the expression with a new parameter of the same name and discarding any other elements of the SQL expression, such as SQL functions, etc. The specific case would be statements that were constructed against ORM entities rather than plain :class:`.Table` instances, but would occur if the statement were invoked with a :class:`.Session` or a :class:`.Connection`. :class:`.Update` part of the issue was present in both 2.0 and 1.4 and is backported to 1.4. For 1.4, also backports the sqlalchemy.testing.Variation update to the variation() API. Fixes: #9075 Change-Id: Ie954bc1f492ec6a566163588182ef4910c7ee452 (cherry picked from commit b5b864e0fe50243a94c0ef04fddda6fa446c1524)
* happy new year 2023Mike Bayer2023-01-0323-23/+23
| | | | Change-Id: I14db8e9c69a832b0f5dae8036db3c0a70bb49edd
* link to with_variant() narrative from API docMike Bayer2023-01-031-0/+5
| | | | | Change-Id: I5d8e4d7cb7871bedebe0fe89758be441e64b94c6 (cherry picked from commit 7f86be997eea27bc994b25c4fb65d72b3d4567f9)
* ensure whereclause, returning copied as tuplesMike Bayer2022-12-281-7/+7
| | | | | | | | | | | Fixed issue in the internal SQL traversal for DML statements like :class:`_dml.Update` and :class:`_dml.Delete` which would cause among other potential issues, a specific issue using lambda statements with the ORM update/delete feature. Fixes: #9033 Change-Id: I76428049cb767ba302fbea89555114bf63ab8687 (cherry picked from commit e68173bf7d296b2948abed06f79c7cbd0ab66b0d)
* pass more contextual information to PyWrapper param createMike Bayer2022-12-272-7/+17
| | | | | | | | | | | Fixed issue in lambda SQL feature where the calculated type of a literal value would not take into account the type coercion rules of the "compared to type", leading to a lack of typing information for SQL expressions, such as comparisons to :class:`.JSON` elements and similar. Fixes: #9029 Change-Id: I381c8d7458d98ba762313dee9ec47a9c1881f74a (cherry picked from commit f63d7e33ec785a5ea4fbc77963c537be26b8419b)
* add joins_implicitly to column_valued()Mike Bayer2022-12-201-2/+12
| | | | | | | | | | | | | | Added parameter :paramref:`.FunctionElement.column_valued.joins_implicitly`, which is useful in preventing the "cartesian product" warning when making use of table-valued or column-valued functions. This parameter was already introduced for :meth:`.FunctionElement.table_valued` in :ticket:`7845`, however it failed to be added for :meth:`.FunctionElement.column_valued` as well. Fixes: #9009 Change-Id: Ifb72fbcb4f4d2998e730d6f85ec7280df3bf3d47 (cherry picked from commit 567878e5c67d08c561dd064fe6dc25e4db7349e7)
* implement literal_binds with expanding + bind_expressionMike Bayer2022-12-151-9/+60
| | | | | | | | | | | | Fixed bug where SQL compilation would fail (assertion fail in 2.0, NoneType error in 1.4) when using an expression whose type included :meth:`_types.TypeEngine.bind_expression`, in the context of an "expanding" (i.e. "IN") parameter in conjunction with the ``literal_binds`` compiler parameter. Fixes: #8989 Change-Id: Ic9fd27b46381b488117295ea5a492d8fc158e39f (cherry picked from commit 8c6de3c2c43ab372cbbe76464b4c5be3b6457252)
* Fix positional compiling bugsFederico Caselli2022-12-011-20/+89
| | | | | | | | | | | | Fixed a series of issues regarding positionally rendered bound parameters, such as those used for SQLite, asyncpg, MySQL and others. Some compiled forms would not maintain the order of parameters correctly, such as the PostgreSQL ``regexp_replace()`` function as well as within the "nesting" feature of the :class:`.CTE` construct first introduced in :ticket:`4123`. Fixes: #8827 Change-Id: I9813ed7c358cc5c1e26725c48df546b209a442cb (cherry picked from commit 0f2baae6bf72353f785bad394684f2d6fa53e0ef)
* Merge "avoid putting annotated columns in sets" into rel_1_4mike bayer2022-11-262-6/+6
|\
| * avoid putting annotated columns in setsMike Bayer2022-11-142-6/+6
| | | | | | | | | | | | | | | | | | | | backporting a small bit of the changes made for the 2.0 version of #8796. See if the changes apply cleanly to the 1.4 branch. Fixes: #8796 Change-Id: I8118511a10beb38c545a55c962a18a77611293af
* | Explicitly state what happens if `order_by` is called more than once. (#8791)Eitan Mosenkis2022-11-141-3/+4
| | | | | | | | | | | | | | | | | | | | * Explicitly state what happens if `order_by` is called more than once. The existing docs cover how to clear existing `order_by` clauses but don't actually describe the behavior of calling `order_by` multiple times with different clauses. * Also update Select.order_by. (cherry picked from commit 9237bf15e612ba82555444751bd69dc2a831e7f4)
* | add informative exception context for literal renderMike Bayer2022-11-143-10/+32
|/ | | | | | | | | | | An informative re-raise is now thrown in the case where any "literal bindparam" render operation fails, indicating the value itself and the datatype in use, to assist in debugging when literal params are being rendered in a statement. Fixes: #8800 Change-Id: Id658f8b03359312353ddbb0c7563026239579f7b (cherry picked from commit c7baf6e0aa624c9378c3bc3c4923d1e188d62dc9)
* Merge "ensure anon_map is passed for most annotated traversals" into rel_1_4mike bayer2022-11-115-11/+57
|\
| * ensure anon_map is passed for most annotated traversalsMike Bayer2022-11-115-11/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can cache the annotated cache key for Table, but for selectables it's not safe, as it fails to pass the anon_map along and creates many redudant structures in observed test scenario. It is likely safe for a Column that's mapped to a Table also, however this is not implemented here. Will have to see if that part needs adjusting. Fixed critical memory issue identified in cache key generation, where for very large and complex ORM statements that make use of lots of ORM aliases with subqueries, cache key generation could produce excessively large keys that were orders of magnitude bigger than the statement itself. Much thanks to Rollo Konig Brock for their very patient, long term help in finally identifying this issue. Also within TypeEngine objects, when we generate elements for instance variables, skip the None elements at least. this also saves on tuple complexity. Fixes: #8790 Change-Id: I448ddbfb45ae0a648815be8dad4faad7d1977427 (cherry picked from commit 88c240d907a9ae3b5caf766009edd196a30cece3)
* | establish consistency for RETURNING column labelsMike Bayer2022-11-112-5/+11
|/ | | | | | | | | | | | | | | | | | | | | | For the PostgreSQL and SQL Server dialects only, adjusted the compiler so that when rendering column expressions in the RETURNING clause, the "non anon" label that's used in SELECT statements is suggested for SQL expression elements that generate a label; the primary example is a SQL function that may be emitting as part of the column's type, where the label name should match the column's name by default. This restores a not-well defined behavior that had changed in version 1.4.21 due to :ticket:`6718`, :ticket:`6710`. The Oracle dialect has a different RETURNING implementation and was not affected by this issue. Version 2.0 features an across the board change for its widely expanded support of RETURNING on other backends. Fixed issue in the Oracle dialect where an INSERT statement that used ``insert(some_table).values(...).returning(some_table)`` against a full :class:`.Table` object at once would fail to execute, raising an exception. Fixes: #8770 Change-Id: I2ab078a214a778ffe1720dbd864ae4c105a0691d (cherry picked from commit c8a7b67181d31634355150fc0379ec0e780ff728)
* apply basic escaping to anon_labels unconditionallyMike Bayer2022-10-271-1/+6
| | | | | | | | | | | | | Fixed issue which prevented the :func:`_sql.literal_column` construct from working properly within the context of a :class:`.Select` construct as well as other potential places where "anonymized labels" might be generated, if the literal expression contained characters which could interfere with format strings, such as open parenthesis, due to an implementation detail of the "anonymous label" structure. Fixes: #8724 Change-Id: I3089124fbd055a011c8a245964258503b717d941 (cherry picked from commit caa9f0ff98d44359f5162bca8e7fe7bcaa2989a7)
* clarify precedence docsMike Bayer2022-10-031-7/+14
| | | | | | Change-Id: I748f2736eb6382c8625b3419a82785b48766d8f7 references: #8584 (cherry picked from commit b295a3b58f13d566c37244448218e4287f5e47ee)
* remove should_nest behavior for contains_eager()Mike Bayer2022-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | Fixed regression for 1.4 in :func:`_orm.contains_eager` where the "wrap in subquery" logic of :func:`_orm.joinedload` would be inadvertently triggered for use of the :func:`_orm.contains_eager` function with similar statements (e.g. those that use ``distinct()``, ``limit()`` or ``offset()``). This is not appropriate for :func:`_orm.contains_eager` which has always had the contract that the user-defined SQL statement is unmodified with the exception of adding the appropriate columns. Also includes an adjustment to the assertion in Label._make_proxy() which was there to prevent a fixed label name from being anonymized; if the label is already anonymous, the change should proceed. This logic was being hit before the contains_eager behavior was adjusted. With the adjustment, this code is not used. Fixes: #8569 Change-Id: I161e65041c0162fd2b83cbef40f57a50fcfaf0fd (cherry picked from commit 57b400f07951f0ae8651ca38338ec5be1d222c7e)
* break out text() from TextualSelect for col matchingMike Bayer2022-09-191-1/+15
| | | | | | | | | | | Fixed issue where mixing "*" with additional explicitly-named column expressions within the columns clause of a :func:`_sql.select` construct would cause result-column targeting to sometimes consider the label name or other non-repeated names to be an ambiguous target. Fixes: #8536 Change-Id: I3c845eaf571033e54c9208762344f67f4351ac3a (cherry picked from commit 78327d98be9236c61f950526470f29b184dabba6)
* include TableClause.schema in cache keyMike Bayer2022-08-301-0/+1
| | | | | | | | | | | | Fixed issue where use of the :func:`_sql.table` construct, passing a string for the :paramref:`_sql.table.schema` parameter, would fail to take the "schema" string into account when producing a cache key, thus leading to caching collisions if multiple, same-named :func:`_sql.table` constructs with different schemas were used. Fixes: #8441 Change-Id: Ic4b55b3e8ec53b4c88ba112691bdf60ea1d4c448 (cherry picked from commit 613642d9639f47ad11ab62a3fa71f6132edbaa0d)
* apply consistent ORM mutable notes for all mutable SQL typesMike Bayer2022-08-301-1/+30
| | | | | | | | | | | | | in https://github.com/sqlalchemy/sqlalchemy/discussions/8447 I was surprised that we didnt have any notes about using Mutable for ARRAY classes, since we have them for HSTORE and JSON. Add a consistent topic box for these so we have something to point towards. Change-Id: Idfa1b2cbee67024545f4fa299e4c875075ec7d3f (cherry picked from commit 2f146b172ad228e40f1e8d5f1d2abc888ae5e669)
* more function adjustmentsMike Bayer2022-08-221-1/+1
| | | | | | | | | the inherited-members feature works very poorly and inconsistently in sphinx. just dont use it here as it refuses to exclude ColumnOperators methods Change-Id: Ic50865c9901e7225a99ff7f33454da15ff91b12f (cherry picked from commit 25fa4c0250730958c39676007cc39df7b0ee2124)
* remove erroneous note about future metadataMike Bayer2022-08-171-3/+0
| | | | | | | this change was already applied Change-Id: I24cfdc1912b77f98ae6d0f3865cabd223553fc79 (cherry picked from commit 0eea54e84df104ffe8bc246eb82e4a7a2cf05079)
* deep compare CTEs before considering them conflictingMike Bayer2022-08-051-4/+13
| | | | | | | | | | | | Fixed issue where referencing a CTE multiple times in conjunction with a polymorphic SELECT could result in multiple "clones" of the same CTE being constructed, which would then trigger these two CTEs as duplicates. To resolve, the two CTEs are deep-compared when this occurs to ensure that they are equivalent, then are treated as equivalent. Fixes: #8357 Change-Id: I1f634a9cf7a6c4256912aac1a00506aecea3b0e2 (cherry picked from commit 85fa363c846f4ed287565c43c32e2cca29470e25)
* update quoted_name docMike Bayer2022-08-041-1/+2
| | | | | | Fixes: #8339 Change-Id: If78bc9babfdc6a4dde4e65d72858ac7a402cbb4d (cherry picked from commit dc5a1c482ee1a8faf15fd81db866e5f72c1c719f)
* Update to flake8 5.Federico Caselli2022-07-314-15/+19
| | | | | Change-Id: I5a241a70efba68bcea9819ddce6aebc25703e68d (cherry picked from commit f8c4dba4e9f130c18ce00597c036bc26ae7abf90)
* check for TypeDecorator when handling getitemMike Bayer2022-07-192-2/+27
| | | | | | | | | | Fixed issue where :class:`.TypeDecorator` would not correctly proxy the ``__getitem__()`` operator when decorating the :class:`.ARRAY` datatype, without explicit workarounds. Fixes: #7249 Change-Id: I3273572b4757e41fb5952639cb867314227d368a (cherry picked from commit 1e01fab7e600c53284eabceceab5706e4074eb2e)
* use concat() directly for contains, startswith, endswithMike Bayer2022-07-172-7/+22
| | | | | | | | | | | | | | | | Adjusted the SQL compilation for string containment functions ``.contains()``, ``.startswith()``, ``.endswith()`` to force the use of the string concatenation operator, rather than relying upon the overload of the addition operator, so that non-standard use of these operators with for example bytestrings still produces string concatenation operators. To accommodate this, needed to add a new _rconcat operator function, which is private, as well as a fallback in concat_op() that works similarly to Python builtin ops. Fixes: #8253 Change-Id: I2b7f56492f765742d88cb2a7834ded6a2892bd7e (cherry picked from commit 85a88df13ab8d217331cf98392544a888b4d7df3)
* support "SELECT *" for ORM queriesMike Bayer2022-07-101-0/+9
| | | | | | | | | | | | | | | | | | | A :func:`_sql.select` construct that is passed a sole '*' argument for ``SELECT *``, either via string, :func:`_sql.text`, or :func:`_sql.literal_column`, will be interpreted as a Core-level SQL statement rather than as an ORM level statement. This is so that the ``*``, when expanded to match any number of columns, will result in all columns returned in the result. the ORM- level interpretation of :func:`_sql.select` needs to know the names and types of all ORM columns up front which can't be achieved when ``'*'`` is used. If ``'*`` is used amongst other expressions simultaneously with an ORM statement, an error is raised as this can't be interpreted correctly by the ORM. Fixes: #8235 Change-Id: Ic8e84491e14acdc8570704eadeaeaf6e16b1e870 (cherry picked from commit 3916bfc9ccf2904f69498075849a82ceee225b3a)
* generalize sql server check for id col to accommodate ORM casesMike Bayer2022-07-052-0/+26
| | | | | | | | | | | | | | | Fixed issues that prevented the new usage patterns for using DML with ORM objects presented at :ref:`orm_dml_returning_objects` from working correctly with the SQL Server pyodbc dialect. Here we add a step to look in compile_state._dict_values more thoroughly for the keys we need to determine "identity insert" or not, and also add a new compiler variable dml_compile_state so that we can skip the ORM's compile_state if present. Fixes: #8210 Change-Id: Idbd76bb3eb075c647dc6c1cb78f7315c821e15f7 (cherry picked from commit 5806428800d2f1ac775156f90497a2fc3a644f35)
* fix formatting problemsMike Bayer2022-07-031-4/+5
| | | | | Change-Id: Ib55fe1c60130a45bfbf28de5c74cfe7a30418bb3 (cherry picked from commit 4b3f204d07d53ae09b59ce8f33b534f26a605cd4)
* Merge "Normalize postgresql docs links to point to current" into rel_1_4mike bayer2022-06-182-10/+10
|\
| * Normalize postgresql docs links to point to currentFederico Caselli2022-06-182-10/+10
| | | | | | | | | | Change-Id: Ib7d3ea7ff3356ff8a2f935892d904a69dbc25c3e (cherry picked from commit 3bde1eae31212b5bc2c6652dca52f70fb79d5950)
* | Allow NUMERIC()/DECIMAL() IDENTITY columnsGord Thompson2022-06-183-1/+8
|/ | | | | | | | | | | | | Fixed issue where :class:`.Table` objects that made use of IDENTITY columns with a :class:`.Numeric` datatype would produce errors when attempting to reconcile the "autoincrement" column, preventing construction of the :class:`.Column` from using the :paramref:`.Column.autoincrement` parameter as well as emitting errors when attempting to invoke an :class:`.Insert` construct. Fixes: #8111 Change-Id: Iaacc4eebfbafb42fa18f9a1a4f43cb2b6b91d28a (cherry picked from commit a134956c4e4564844c33302ddf27a70102fe00a8)
* Merge "restore parameter escaping for public methods" into rel_1_4mike bayer2022-06-091-9/+28
|\
| * restore parameter escaping for public methodsMike Bayer2022-06-091-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjusted the fix made for :ticket:`8056` which adjusted the escaping of bound parameter names with special characters such that the escaped names were translated after the SQL compilation step, which broke a published recipe on the FAQ illustrating how to merge parameter names into the string output of a compiled SQL string. The change restores the escaped names that come from ``compiled.params`` and adds a conditional parameter to :meth:`.SQLCompiler.construct_params` named ``escape_names`` that defaults to ``True``, restoring the old behavior by default. Fixes: #8113 Change-Id: I9cbedb1080bc06d51f287fd2cbf26aaab1c74653 (cherry picked from commit 105cd180856309cf5abf24f59b782a1bcd8210d6)
* | Merge "fix race conditions in lambda statements" into rel_1_4mike bayer2022-06-093-11/+34
|\ \ | |/ |/|
| * fix race conditions in lambda statementsMike Bayer2022-06-083-11/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed multiple observed race conditions related to :func:`.lambda_stmt`, including an initial "dogpile" issue when a new Python code object is initially analyzed among multiple simultaneous threads which created both a performance issue as well as some internal corruption of state. Additionally repaired observed race condition which could occur when "cloning" an expression construct that is also in the process of being compiled or otherwise accessed in a different thread due to memoized attributes altering the ``__dict__`` while iterated, for Python versions prior to 3.10; in particular the lambda SQL construct is sensitive to this as it holds onto a single statement object persistently. The iteration has been refined to use ``dict.copy()`` with or without an additional iteration instead. Fixes: #8098 Change-Id: I4e0b627bfa187f1780dc68ec81b94db1c78f846a (cherry picked from commit 117878f7870377f143917a22160320a891eb0211)
* | Merge "graceful degrade for FKs not reflectable" into rel_1_4mike bayer2022-06-082-4/+28
|\ \ | |/ |/|
| * graceful degrade for FKs not reflectableMike Bayer2022-06-072-4/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed bugs involving the :paramref:`.Table.include_columns` and the :paramref:`.Table.resolve_fks` parameters on :class:`.Table`; these little-used parameters were apparently not working for columns that refer to foreign key constraints. In the first case, not-included columns that refer to foreign keys would still attempt to create a :class:`.ForeignKey` object, producing errors when attempting to resolve the columns for the foreign key constraint within reflection; foreign key constraints that refer to skipped columns are now omitted from the table reflection process in the same way as occurs for :class:`.Index` and :class:`.UniqueConstraint` objects with the same conditions. No warning is produced however, as we likely want to remove the include_columns warnings for all constraints in 2.0. In the latter case, the production of table aliases or subqueries would fail on an FK related table not found despite the presence of ``resolve_fks=False``; the logic has been repaired so that if a related table is not found, the :class:`.ForeignKey` object is still proxied to the aliased table or subquery (these :class:`.ForeignKey` objects are normally used in the production of join conditions), but it is sent with a flag that it's not resolvable. The aliased table / subquery will then work normally, with the exception that it cannot be used to generate a join condition automatically, as the foreign key information is missing. This was already the behavior for such foreign key constraints produced using non-reflection methods, such as joining :class:`.Table` objects from different :class:`.MetaData` collections. Fixes: #8100 Fixes: #8101 Change-Id: Ifa37a91bd1f1785fca85ef163eec031660d9ea4d (cherry picked from commit 40e3c0da5be7dd526866bfc63590fc5621a9bd6e)
* | migrate labels to new tutorialMike Bayer2022-06-074-66/+28
|/ | | | | | | | other org changes and some sections from old tutorial ported to new tutorial. Change-Id: Ic0fba60ec82fff481890887beef9ed0fa271875a (Cherry-picked and independently modified)
* Docs Update - Add **kwargs to CaseInsensitiveComparator docs (#8063)Justin Crown2022-06-041-2/+2
| | | | | | | | | | | | | | | * Add **kwargs to CaseInsensitiveComparator docs * add kwargs to other operate examples Change-Id: I70a1e68bca27c2355ad3b7c5bbc538027f112bd9 * missed one entry Change-Id: Ieb4a18ab6d96e588e9ec7672cfa65fe2fd8301e5 Co-authored-by: Federico Caselli <cfederico87@gmail.com> (cherry picked from commit 1508aed47261fe17180aa12fb312aebb0dd3c615)
* propagate proxy_key from WrapsColumnExpressionMike Bayer2022-06-011-0/+8
| | | | | | | | | | | | | | this allows cast() of a label() to propagate the proxy key outwards in the same way that it apparently works at the SQL level. This is stuffing even more rules into naming so basically seeing how far we can go without other cases starting to fail. Fixes: #8084 Change-Id: I20bd97dae798fee6492334c06934e807d0f269ef (cherry picked from commit 14250f2668151f1c4df86dbf962c771e9788111e)
* raise informative error when selectable can't be extendedMike Bayer2022-05-311-3/+14
| | | | | | | | | | | | An informative error is raised for the use case where :meth:`.Insert.from_select` is being passed a "compound select" object such as a UNION, yet the INSERT statement needs to append additional columns to support Python-side or explicit SQL defaults from the table metadata. In this case a subquery of the compound object should be passed. Fixes: #8073 Change-Id: Ic4a5dbf84ec49d2451901be05cb9cf6ae93f02b7 (cherry picked from commit 7474df2159f89d684d32aabb15014ef95cea1641)
* move bindparam quote application from compiler to defaultMike Bayer2022-05-291-36/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in 296c84313ab29bf9599634f3 for #5653 we generalized Oracle's parameter escaping feature into the compiler, so that it could also work for PostgreSQL. The compiler used quoted names within parameter dictionaries, which then led to the complexity that all functions which interpreted keys from the compiled_params dict had to also quote the param names to use the dictionary. This extra complexity was not added to the ORM peristence.py however, which led to the versioning id feature being broken as well as other areas where persistence.py relies on naming schemes present in context.compiled_params. It also was not added to the "processors" lookup which led to #8053, that added this escaping to that part of the compiler. To both solve the whole problem as well as simplify the compiler quite a bit, move the actual application of the escaped names to be as late as possible, when default.py builds the final list of parameters. This is more similar to how it worked previously where OracleExecutionContext would be late-applying these escaped names. This re-establishes context.compiled_params as deterministically named regardless of dialect in use and moves out the complexity of the quoted param names to be only at the cursor.execute stage. Fixed bug, likely a regression from 1.3, where usage of column names that require bound parameter escaping, more concretely when using Oracle with column names that require quoting such as those that start with an underscore, or in less common cases with some PostgreSQL drivers when using column names that contain percent signs, would cause the ORM versioning feature to not work correctly if the versioning column itself had such a name, as the ORM assumes certain bound parameter naming conventions that were being interfered with via the quotes. This issue is related to :ticket:`8053` and essentially revises the approach towards fixing this, revising the original issue :ticket:`5653` that created the initial implementation for generalized bound-parameter name quoting. Fixes: #8056 Change-Id: I57b064e8f0d070e328b65789c30076f6a0ca0fef (cherry picked from commit a48b597d0cafa1dd7fc46be99eb808fd4cb0a347)
* apply bindparam escape name to processors dictionaryMike Bayer2022-05-251-1/+9
| | | | | | | | | | | | | | Fixed SQL compiler issue where the "bind processing" function for a bound parameter would not be correctly applied to a bound value if the bound parameter's name were "escaped". Concretely, this applies, among other cases, to Oracle when a :class:`.Column` has a name that itself requires quoting, such that the quoting-required name is then used for the bound parameters generated within DML statements, and the datatype in use requires bind processing, such as the :class:`.Enum` datatype. Fixes: #8053 Change-Id: I39d060a87e240b4ebcfccaa9c535e971b7255d99 (cherry picked from commit 4d58ca05e83048e999059a8c2c2e67cb77abf976)
* favor bool_op over op in comparisonMike Bayer2022-05-181-6/+12
| | | | | | | | | there's no need to use the is_comparison parameter anymore as bool_op() works better and in 2.0 also does typing correctly. Change-Id: I9e92b665b112d40d90e539003b0efe00ed7b075f (cherry picked from commit deb9bcc0d97dd8b38dfccb340a5fc1f880202ff6)
* fix most sphinx warningsMike Bayer2022-05-162-9/+8
| | | | | | | | still can't figure out the warnings with some of the older changelog files. Fixes: #7946 Change-Id: Id657ab23008eed0b133fed65b2f9ea75a626215c
* raise for same param name in expanding + non expandingMike Bayer2022-05-151-0/+9
| | | | | | | | | | | | | | An informative error is raised if two individual :class:`.BindParameter` objects share the same name, yet one is used within an "expanding" context (typically an IN expression) and the other is not; mixing the same name in these two different styles of usage is not supported and typically the ``expanding=True`` parameter should be set on the parameters that are to receive list values outside of IN expressions (where ``expanding`` is set by default). Fixes: #8018 Change-Id: Ie707f29680eea16b9e421af93560ac1958e11a54 (cherry picked from commit f9fccdeeb6749d10aeec458f1a549906d58ddad8)
* docs(types) Fix missing import from sqlalchemy (#7978)khashashin2022-05-031-0/+2
| | | | | | | | | | | | | * docs(types) Fix missing import from sqlalchemy The sample code is missing the import of Enum from sqlalchemy, which might confuse the reader, since we are using another enum type from Python itself here. So it makes sense to clarify that here. * fix whitespaces Change-Id: I019bbed8a7278f60e7239160ea4c99ecd2519d3b Co-authored-by: Federico Caselli <cfederico87@gmail.com> (cherry picked from commit f89a202d60215b13e3733a3ea950473962b3cf67)
View Lorry Controller Status