delta/python-packages/sqlalchemy.git/lib/sqlalchemy/engine/create.py, branch rel_1_4 github.com: zzzeek/sqlalchemy.git remove "listeners" docstring 2023-03-15T14:11:19+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-03-15T14:09:57+00:00 73515434c88c73cb81c738ba2ec84953607b9d97 this should have been removed with #4638. Fixes: #9492 Change-Id: If82dba7e63382e921aceb0c01d88f0977b7f5e8d (cherry picked from commit 7fd3b4747d2935effd9e0c2bbe72f080df4ffc50) 
this should have been removed with #4638.

Fixes: #9492
Change-Id: If82dba7e63382e921aceb0c01d88f0977b7f5e8d
(cherry picked from commit 7fd3b4747d2935effd9e0c2bbe72f080df4ffc50)
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
ensure pool.reset event always called for reset 2022-10-30T18:18:38+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-10-25T20:00:50+00:00 d593d63d81fe7db0bebaa2371366343db33ed576 Fixed issue where the :meth:`.PoolEvents.reset` event hook would not be called when a :class:`.Connection` were closed which already closed its own transaction. Logic that bypasses the "rollback on return" behavior of the pool was also skipping the event hook being emitted, preventing custom pool reset schemes from being used within this hook. This was a regression that appeared in version 1.4. For version 1.4, the hook is still not called in the case of an asyncio connection that is being discarded due to garbage collection. Version 2.0 will feature an improved version of :meth:`.PoolEvents.reset` which also receives contextual information about the reset, so that comprehensive "custom connection reset" schemes can be devised. Existing custom reset schemes that make use of :meth:`.PoolEvents.checkin` remain usable as they typically only need to deal with connections that are to be re-used. Change-Id: Ie17c4f55d02beb6f570b9de6b3044baffa7d6df6 Fixes: #8717 (cherry picked from commit bb8c36c5d2622e6e7033dc59dc98da0926ba7c00) 
Fixed issue where the :meth:`.PoolEvents.reset` event hook would
not be called when a :class:`.Connection` were closed which already
closed its own transaction.  Logic that bypasses the "rollback on return"
behavior of the pool was also skipping the event hook being emitted,
preventing custom pool reset schemes from being used within this hook.
This was a regression that appeared in version 1.4.

For version 1.4, the hook is still not called in the case of an asyncio
connection that is being discarded due to garbage collection. Version 2.0
will feature an improved version of :meth:`.PoolEvents.reset` which also
receives contextual information about the reset, so that comprehensive
"custom connection reset" schemes can be devised.  Existing custom
reset schemes that make use of :meth:`.PoolEvents.checkin` remain
usable as they typically only need to deal with connections that are to
be re-used.

Change-Id: Ie17c4f55d02beb6f570b9de6b3044baffa7d6df6
Fixes: #8717
(cherry picked from commit bb8c36c5d2622e6e7033dc59dc98da0926ba7c00)
link to main isolation level document 2022-07-13T14:54:52+00:00 Mike Bayer mike_mp@zzzcomputing.com 2022-07-13T14:54:52+00:00 899f5d05363f144f60cfbc30717df0d673e1d51f this was already in 2.0. a few more corrections coming Change-Id: Id94eee9081fd5174bad2275f544010e7cb467454 references: #8252 
this was already in 2.0.  a few more corrections coming

Change-Id: Id94eee9081fd5174bad2275f544010e7cb467454
references: #8252
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
changelog, doc edits 2021-09-22T15:16:04+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-09-22T15:16:04+00:00 9ed0d194bd7918a1e87cc8e02a55fcd8134de66d Change-Id: Iafb50de7e28626d9cee755db9c05ac7189b4d963 
Change-Id: Iafb50de7e28626d9cee755db9c05ac7189b4d963
clarify "encoding" parameter further 2021-09-20T13:55:24+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-09-20T13:48:57+00:00 8a10b1e4506c27773628fff1f3d99ca850211862 Prevent any reading of this parameter that would omit that it is not used under Python 3 and in Python 2 is not used very much either. Fixes: #7050 Change-Id: Iaf619f1ee164fc58afe710d11627ed6368d74343 
Prevent any reading of this parameter that would omit that it
is not used under Python 3 and in Python 2 is not used very
much either.

Fixes: #7050
Change-Id: Iaf619f1ee164fc58afe710d11627ed6368d74343
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
Pass URL object, not the string, to on_connect_url 2021-06-06T14:12:05+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-06-06T14:12:05+00:00 03633a6462ee16a1348acb98fe0323c74eb9ba85 The fix for pysqlcipher released in version 1.4.3 :ticket:`5848` was unfortunately non-working, in that the new ``on_connect_url`` hook was erroneously not receiving a ``URL`` object under normal usage of :func:`_sa.create_engine` and instead received a string that was unhandled; the test suite failed to fully set up the actual conditions under which this hook is called. This has been fixed. Fixes: #6586 Change-Id: I3bf738daec35877a10fdad740f08dca9e7420829 
The fix for pysqlcipher released in version 1.4.3 :ticket:`5848` was
unfortunately non-working, in that the new ``on_connect_url`` hook was
erroneously not receiving a ``URL`` object under normal usage of
:func:`_sa.create_engine` and instead received a string that was unhandled;
the test suite failed to fully set up the actual conditions under which
this hook is called. This has been fixed.

Fixes: #6586
Change-Id: I3bf738daec35877a10fdad740f08dca9e7420829
Add new "sync once" mode for pool.connect 2021-04-22T02:31:42+00:00 Mike Bayer mike_mp@zzzcomputing.com 2021-04-21T18:44:45+00:00 37414a752b0036334d0f31ac8cd3aff749c3898b Fixed critical regression caused by the change in :ticket`5497` where the connection pool "init" phase no longer occurred within mutexed isolation, allowing other threads to proceed with the dialect uninitialized, which could then impact the compilation of SQL statements. This issue is essentially the same regression which was fixed many years ago in :ticket:`2964` in dd32540dabbee0678530fb1b0868d1eb41572dca, which was missed this time as the test suite fo that issue only tested the pool in isolation, and assumed the "first_connect" event would be used by the Engine. However :ticket:`5497` stopped using "first_connect" and no test detected the lack of mutexing, that has been resolved here through the addition of more tests. This fix also identifies what is probably a bug in earlier versions of SQLAlchemy where the "first_connect" handler would be cancelled if the initializer failed; this is evidenced by test_explode_in_initializer which was doing a reconnect due to c.rollback() yet wasn't hanging. We now solve this issue by preventing the manufactured Connection from ever reconnecting inside the first_connect handler. Also remove the "_sqla_unwrap" test attribute; this is almost not used anymore however we can use a more targeted wrapper supplied by the testing.engines.proxying_engine function. See if we can also open up Oracle for "ad hoc engines" tests now that we have better connection management logic. Fixes: #6337 Change-Id: I4a3476625c4606f1a304dbc940d500325e8adc1a 
Fixed critical regression caused by the change in :ticket`5497` where the
connection pool "init" phase no longer occurred within mutexed isolation,
allowing other threads to proceed with the dialect uninitialized, which
could then impact the compilation of SQL statements.

This issue is essentially the same regression which was fixed many years
ago in :ticket:`2964` in dd32540dabbee0678530fb1b0868d1eb41572dca,
which was missed this time as the test suite fo
that issue only tested the pool in isolation, and assumed the
"first_connect" event would be used by the Engine.  However
:ticket:`5497` stopped using "first_connect" and no test detected
the lack of mutexing, that has been resolved here through
the addition of more tests.

This fix also identifies what is probably a bug in earlier versions
of SQLAlchemy where the "first_connect" handler would be cancelled
if the initializer failed; this is evidenced by
test_explode_in_initializer which was doing a reconnect due to
c.rollback() yet wasn't hanging.  We now solve this issue by
preventing the manufactured Connection from ever reconnecting
inside the first_connect handler.

Also remove the "_sqla_unwrap" test attribute; this is almost
not used anymore however we can use a more targeted
wrapper supplied by the testing.engines.proxying_engine
function.

See if we can also open up Oracle for "ad hoc engines" tests
now that we have better connection management logic.

Fixes: #6337
Change-Id: I4a3476625c4606f1a304dbc940d500325e8adc1a