delta/python-packages/sqlalchemy.git/lib/sqlalchemy/sql/coercions.py, branch rel_1_4 github.com: zzzeek/sqlalchemy.git happy new year 2023 2023-01-03T17:50:29+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-01-03T17:50:29+00:00 4f5970525403c98d46ed1a60f7816bc413a8c523 Change-Id: I14db8e9c69a832b0f5dae8036db3c0a70bb49edd 
Change-Id: I14db8e9c69a832b0f5dae8036db3c0a70bb49edd
pass more contextual information to PyWrapper param create 2022-12-27T19:05:15+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-12-27T17:29:38+00:00 4c80fad2968c7a5953809a9c030886a03151a514 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) 
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)
use bindparam_type in BinaryElementImpl._post_coercion if available 2022-05-01T16:29:29+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-05-01T16:28:36+00:00 55ac391ef92a46556c1579899feef051296acd4b Fixed an issue where using :func:`.bindparam` with no explicit data or type given could be coerced into the incorrect type when used in expressions such as when using :meth:`.ARRAY.comparator.any` and :meth:`.ARRAY.comparator.all`. Fixes: #7979 Change-Id: If7779e713c9a3a5fee496b66e417cfd3fca5b1f9 (cherry picked from commit 889cbe53121c8fd50c845357dd52b24594346b68) 
Fixed an issue where using :func:`.bindparam` with no explicit data or type
given could be coerced into the incorrect type when used in expressions
such as when using :meth:`.ARRAY.comparator.any` and
:meth:`.ARRAY.comparator.all`.

Fixes: #7979
Change-Id: If7779e713c9a3a5fee496b66e417cfd3fca5b1f9
(cherry picked from commit 889cbe53121c8fd50c845357dd52b24594346b68)
happy new year 2022 2022-01-06T20:59:47+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-01-06T20:59:47+00:00 2f370229d63665ffae72a9f8a37800b4d70cf6a1 Change-Id: Ic38dbc640aa0fe8a784a5b5e57c45a41eb0ea01b 
Change-Id: Ic38dbc640aa0fe8a784a5b5e57c45a41eb0ea01b
Warn when caching is disabled / document 2021-12-06T23:28:50+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-12-03T19:04:05+00:00 8d5ed4c39eed6a13397f43159278138bbe1a4a1b 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 (cherry picked from commit 22deafe15289d2be55682e1632016004b02b62c0) 
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
(cherry picked from commit 22deafe15289d2be55682e1632016004b02b62c0)
Warn when trying to execute a query object with a session. 2021-10-04T18:33:29+00:00 Federico Caselli cfederico87@gmail.com 2021-10-01T20:16:14+00:00 3f2209776183193552cbc9516710deb6598fd6cd Passing a :class:`.Query` object to :meth:`_orm.Session.execute` is not the intended use of this object, and will now raise a deprecation warning. Fixes: #6284 Change-Id: I30a406d5a72335f9405f10f0a2030a32ccda41b9 
Passing a :class:`.Query` object to :meth:`_orm.Session.execute` is not
the intended use of this object, and will now raise a deprecation warning.

Fixes: #6284
Change-Id: I30a406d5a72335f9405f10f0a2030a32ccda41b9
dont warn for dictionary passed positionally 2021-07-21T20:00:12+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-07-20T15:03:08+00:00 27ec4929198807702190b96d3c00d0291976f49e Fixed issue where use of the :paramref:`_sql.case.whens` parameter passing a dictionary positionally and not as a keyword argument would emit a 2.0 deprecation warning, referring to the deprecation of passing a list positionally. The dictionary format of "whens", passed positionally, is still supported and was accidentally marked as deprecated. Removes warning filter for case statement. Fixes: #6786 Change-Id: I8efd1882563773bec89ae5e34f0dfede77fc4683 
Fixed issue where use of the :paramref:`_sql.case.whens` parameter passing
a dictionary positionally and not as a keyword argument would emit a 2.0
deprecation warning, referring to the deprecation of passing a list
positionally. The dictionary format of "whens", passed positionally, is
still supported and was accidentally marked as deprecated.

Removes warning filter for case statement.

Fixes: #6786
Change-Id: I8efd1882563773bec89ae5e34f0dfede77fc4683
limit None->null coercion to not occur with crud 2021-07-15T19:09:28+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-07-15T15:25:31+00:00 03794d40f31cd1c8501c528eda6c351559c1f739 Fixed issue where type-specific bound parameter handlers would not be called upon in the case of using the :meth:`_sql.Insert.values` method with the Python ``None`` value; in particular, this would be noticed when using the :class:`_types.JSON` datatype as well as related PostgreSQL specific types such as :class:`_postgresql.JSONB` which would fail to encode the Python ``None`` value into JSON null, however the issue was generalized to any bound parameter handler in conjunction with this specific method of :class:`_sql.Insert`. The issue with coercions forcing out ``null()`` may still impact SQL expression usage as well; the change here is limited to crud as the behavior there is relevant to some use cases, which may need to be evaluated separately. Fixes: #6770 Change-Id: If53edad811b37dada7578a89daf395628db058a6 
Fixed issue where type-specific bound parameter handlers would not be
called upon in the case of using the :meth:`_sql.Insert.values` method with
the Python ``None`` value; in particular, this would be noticed when using
the :class:`_types.JSON` datatype as well as related PostgreSQL specific
types such as :class:`_postgresql.JSONB` which would fail to encode the
Python ``None`` value into JSON null, however the issue was generalized to
any bound parameter handler in conjunction with this specific method of
:class:`_sql.Insert`.

The issue with coercions forcing out ``null()`` may still impact
SQL expression usage as well; the change here is limited to crud
as the behavior there is relevant to some use cases, which may
need to be evaluated separately.

Fixes: #6770
Change-Id: If53edad811b37dada7578a89daf395628db058a6
implement independent CTEs 2021-07-12T21:10:58+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-07-12T18:28:19+00:00 204ff1f60cf911b00b7494942fc58bc715dddeed Added new method :meth:`_sql.HasCTE.add_cte` to each of the :func:`_sql.select`, :func:`_sql.insert`, :func:`_sql.update` and :func:`_sql.delete` constructs. This method will add the given :class:`_sql.CTE` as an "independent" CTE of the statement, meaning it renders in the WITH clause above the statement unconditionally even if it is not otherwise referenced in the primary statement. This is a popular use case on the PostgreSQL database where a CTE is used for a DML statement that runs against database rows independently of the primary statement. Fixes: #6752 Change-Id: Ibf635763e40269cbd10f4c17e208850d8e8d0188 
Added new method :meth:`_sql.HasCTE.add_cte` to each of the
:func:`_sql.select`, :func:`_sql.insert`, :func:`_sql.update` and
:func:`_sql.delete` constructs. This method will add the given
:class:`_sql.CTE` as an "independent" CTE of the statement, meaning it
renders in the WITH clause above the statement unconditionally even if it
is not otherwise referenced in the primary statement. This is a popular use
case on the PostgreSQL database where a CTE is used for a DML statement
that runs against database rows independently of the primary statement.

Fixes: #6752
Change-Id: Ibf635763e40269cbd10f4c17e208850d8e8d0188
Replace all http:// links to https:// 2021-07-04T18:54:33+00:00 Federico Caselli cfederico87@gmail.com 2021-07-04T17:29:19+00:00 fb81f9c8d914f9911925dd3f4e77d7fc374b267c Also replace http://pypi.python.org/pypi with https://pypi.org/project Change-Id: I84b5005c39969a82140706472989f2a30b0c7685 
Also replace http://pypi.python.org/pypi with https://pypi.org/project

Change-Id: I84b5005c39969a82140706472989f2a30b0c7685