These changes should be ported from 1.3 back to 1.0 or possibly 0.9 to the extent they are relevant in each version. In 1.3 we hope to turn all deprecation documentation into warnings. (cherry picked from commit 77e9534673d58f2f4c33d16c0ed4e8671cea48b6) Change-Id: I205186cde161af9389af513a425c62ce90dd54d8
Applied on top of a pure run of black -l 79 in I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9, this set of changes resolves all remaining flake8 conditions for those codes we have enabled in setup.cfg. Included are resolutions for all remaining flake8 issues including shadowed builtins, long lines, import order, unused imports, duplicate imports, and docstring issues. Change-Id: I4f72d3ba1380dd601610ff80b8fb06a2aff8b0fe
This is a straight reformat run using black as is, with no edits applied at all. The black run will format code consistently, however in some cases that are prevalent in SQLAlchemy code it produces too-long lines. The too-long lines will be resolved in the following commit that will resolve all remaining flake8 issues including shadowed builtins, long lines, import order, unused imports, duplicate imports, and docstring issues. Change-Id: I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9
Fixed connection pool issue whereby if a disconnection error were raised during the connection pool's "reset on return" sequence in conjunction with an explicit transaction opened against the enclosing :class:`.Connection` object (such as from calling :meth:`.Session.close` without a rollback or commit, or calling :meth:`.Connection.close` without first closing a transaction declared with :meth:`.Connection.begin`), a double-checkin would result, which could then lead towards concurrent checkouts of the same connection. The double-checkin condition is now prevented overall by an assertion, as well as the specific double-checkin scenario has been fixed. Change-Id: If5bb6941e36326846b14918c33ebfdd5604f642e Fixes: #4252 (cherry picked from commit dada909a1009ad2f77063752ac8c13a7808dd916)
Fixed bug in connection pool where a connection could be present in the pool without all of its "connect" event handlers called, if a previous "connect" handler threw an exception; note that the dialects themselves have connect handlers that emit SQL, such as those which set transaction isolation, which can fail if the database is in a non-available state, but still allows a connection. The connection is now invalidated first if any of the connect handlers fail. Change-Id: I61d6f4827a98ab8455f1c3e1c55d046eeccec09a Fixes: #4225 (cherry picked from commit c5437296713288cbfcd323032ca48a75a97e10e5)
Fixed a fairly serious connection pool bug where a connection that is acquired after being refreshed as a result of a user-defined :class:`.DisconnectionError` or due to the 1.2-released "pre_ping" feature would not be correctly reset if the connection were returned to the pool by weakref cleanup (e.g. the front-facing object is garbage collected); the weakref would still refer to the previously invalidated DBAPI connection which would have the reset operation erroneously called upon it instead. This would lead to stack traces in the logs and a connection being checked into the pool without being reset, which can cause locking issues. Change-Id: Iabd9f3a63a1d0207d0de0054a6ced3560818cf9c Fixes: #4184
This test often fails on CI under load and reveals a small race condition within SingleonThreadPool's "cleanup" system. As this pool's "cleanup" system is pretty much never used in any case since this pool is no longer used for SQLite file databases, this race should have little impact, especially since the occasional non-closed connection will get closed out when it's GC'ed in any case. Change-Id: I68aefc0f9bbfc708c95af0497844e65366fc8429
now and it seems like mock might not be doing the right thing. Change-Id: I5c108d82631c9217da54a8ace68d7728c3e204d8
used in this intentionally broken scenario Change-Id: I88ea6fa710da2189e6d47e2d12f5f0fd6f6bb7d4