summaryrefslogtreecommitdiff
path: root/test/engine
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge "don't cache TypeDecorator by default"mike bayer2021-05-061-0/+3
|\
| * don't cache TypeDecorator by defaultMike Bayer2021-05-061-0/+3
| | | | | | | | | | | | | | | | | | | | The :class:`.TypeDecorator` class will now emit a warning when used in SQL compilation with caching unless the ``.cache_ok`` flag is set to ``True`` or ``False``. ``.cache_ok`` indicates that all the parameters passed to the object are safe to be used as a cache key, ``False`` means they are not. Fixes: #6436 Change-Id: Ib1bb7dc4b124e38521d615c2e2e691e4915594fb
* | unify transactional context managersMike Bayer2021-05-051-5/+63
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applied consistent behavior to the use case of calling ``.commit()`` or ``.rollback()`` inside of an existing ``.begin()`` context manager, with the addition of potentially emitting SQL within the block subsequent to the commit or rollback. This change continues upon the change first added in :ticket:`6155` where the use case of calling "rollback" inside of a ``.begin()`` contextmanager block was proposed: * calling ``.commit()`` or ``.rollback()`` will now be allowed without error or warning within all scopes, including that of legacy and future :class:`_engine.Engine`, ORM :class:`_orm.Session`, asyncio :class:`.AsyncEngine`. Previously, the :class:`_orm.Session` disallowed this. * The remaining scope of the context manager is then closed; when the block ends, a check is emitted to see if the transaction was already ended, and if so the block returns without action. * It will now raise **an error** if subsequent SQL of any kind is emitted within the block, **after** ``.commit()`` or ``.rollback()`` is called. The block should be closed as the state of the executable object would otherwise be undefined in this state. Fixes: #6288 Change-Id: I8b21766ae430f0fa1ac5ef689f4c0fb19fc84336
* restore legacy begin_nested()->root transaction behaviorMike Bayer2021-05-021-1/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restored a legacy transactional behavior that was inadvertently removed from the :class:`_engine.Connection` as it was never tested as a known use case in previous versions, where calling upon the :meth:`_engine.Connection.begin_nested` method, when no transaction were present, would not create a SAVEPOINT at all, and would instead only start the outermost transaction alone, and return that :class:`.RootTransaction` object, acting like the outermost transaction. Committing the transaction object returned by :meth:`_engine.Connection.begin_nested` would therefore emit a real COMMIT on the database connection. This behavior is not at all what the 2.0 style connection will do - in 2.0 style, calling :meth:`_future.Connection.begin_nested` will "autobegin" the outer transaction, and then as instructed emit a SAVEPOINT, returning the :class:`.NestedTransaction` object. The outer transaction is committed by calling upon :meth:`_future.Connection.commit`, as is "commit-as-you-go" style usage. In non-"future" mode, while the old behavior is restored, it also emits a 2.0 deprecation warning as this is a legacy behavior. Additionally clarifies and reformats various engine-related documentation, in particular future connection.begin() which was a tire fire. Fixes: #6408 Change-Id: I4b81cc6b481b5493eef4c91bebc03210e2206d39
* Add new "sync once" mode for pool.connectMike Bayer2021-04-214-9/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Support DEFAULT VALUES and VALUES(DEFAULT) individually"mike bayer2021-04-141-0/+1
|\
| * Support DEFAULT VALUES and VALUES(DEFAULT) individuallyMike Bayer2021-04-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where the introduction of the INSERT syntax "INSERT... VALUES (DEFAULT)" was not supported on some backends that do however support "INSERT..DEFAULT VALUES", including SQLite. The two syntaxes are now each individually supported or non-supported for each dialect, for example MySQL supports "VALUES (DEFAULT)" but not "DEFAULT VALUES". Support for Oracle is still not enabled as there are unresolved issues in using RETURNING at the same time. Fixes: #6254 Change-Id: I47959bc826e3d9d2396ccfa290eb084841b02e77
* | Explicitly test for Connection in dialect.has_table()Mike Bayer2021-04-141-0/+7
|/ | | | | | | | | | | | | | The :meth:`_engine.Dialect.has_table` method now raises an informative exception if a non-Connection is passed to it, as this incorrect behavior seems to be common. This method is not intended for external use outside of a dialect. Please use the :meth:`.Inspector.has_table` method or for cross-compatibility with older SQLAlchemy versions, the :meth:`_engine.Engine.has_table` method. Fixes: #5780 Fixes: #6062 Fixes: #6260 Change-Id: I9b2439675167019b68d682edee3dcdcfce836987
* Disallow AliasedReturnsRows from executionMike Bayer2021-04-051-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Executing a :class:`_sql.Subquery` using :meth:`_engine.Connection.execute` is deprecated and will emit a deprecation warning; this use case was an oversight that should have been removed from 1.4. The operation will now execute the underlying :class:`_sql.Select` object directly for backwards compatibility. Similarly, the :class:`_sql.CTE` class is also not appropriate for execution. In 1.3, attempting to execute a CTE would result in an invalid "blank" SQL statement being executed; since this use case was not working it now raises :class:`_exc.ObjectNotExecutableError`. Previously, 1.4 was attempting to execute the CTE as a statement however it was working only erratically. The change also breaks out StatementRole from ReturnsRowsRole, as these roles should not be in the same lineage (some statements don't return rows, the whole class of ReturnsRows that are from clauses are not statements). Consolidate StatementRole and CoerceTextStatementRole as there's no usage difference between these. Simplify some old tests that were trying to make sure that "execution options" didn't transmit from a cte/subquery out to a select; as cte/subuqery() aren't executable in any case the options are removed. Fixes: #6204 Change-Id: I62613b7ab418afdd22c409eae75659e3f52fb65f
* Default caching to opt-out for 3rd party dialectsMike Bayer2021-04-011-0/+95
| | | | | | | | | | | | | | | | | | | Added a new flag to the :class:`_engine.Dialect` class called :attr:`_engine.Dialect.supports_statement_cache`. This flag now needs to be present directly on a dialect class in order for SQLAlchemy's :ref:`query cache <sql_caching>` to take effect for that dialect. The rationale is based on discovered issues such as :ticket:`6173` revealing that dialects which hardcode literal values from the compiled statement, often the numerical parameters used for LIMIT / OFFSET, will not be compatible with caching until these dialects are revised to use the parameters present in the statement only. For third party dialects where this flag is not applied, the SQL logging will show the message "dialect does not support caching", indicating the dialect should seek to apply this flag once they have verified that no per-statement literal values are being rendered within the compilation phase. Fixes: #6184 Change-Id: I6fd5b5d94200458d4cb0e14f2f556dbc25e27e22
* Run trans.close() at end of block if transaction already inactiveMike Bayer2021-03-301-6/+157
| | | | | | | | | | | | Modified the context manager used by :class:`_engine.Transaction` so that an "already detached" warning is not emitted by the ending of the context manager itself, if the transaction were already manually rolled back inside the block. This applies to regular transactions, savepoint transactions, and legacy "marker" transactions. A warning is still emitted if the ``.rollback()`` method is called explicitly more than once. Fixes: #6155 Change-Id: Ib9f9d803bf377ec843d4a8a09da8ebef4b441665
* Add support for aiosqliteFederico Caselli2021-03-243-3/+19
| | | | | | | | Added support for the aiosqlite database driver for use with the SQLAlchemy asyncio extension. Fixes: #5920 Change-Id: Id11a320516a44e886a6f518d2866a0f992413e55
* Replace reset_agent with direct call from connectionMike Bayer2021-03-064-366/+373
| | | | | | | | | | | | | Fixed a regression where the "reset agent" of the connection pool wasn't really being utilized by the :class:`_engine.Connection` when it were closed, and also leading to a double-rollback scenario that was somewhat wasteful. The newer architecture of the engine has been updated so that the connection pool "reset-on-return" logic will be skipped when the :class:`_engine.Connection` explicitly closes out the transaction before returning the pool to the connection. Fixes: #6004 Change-Id: I5d2ac16cac71aa45a00b4b7481d7268bd828a168
* Clarify COMMIT/ROLLBACK logging when autocommit is turned onMike Bayer2021-03-051-0/+85
| | | | | | | | | | | Improved engine logging to note ROLLBACK and COMMIT which is logged while the DBAPI driver is in AUTOCOMMIT mode. These ROLLBACK/COMMIT are library level and do not have any effect when AUTOCOMMIT is in effect, however it's still worthwhile to log as these indicate where SQLAlchemy sees the "transaction" demarcation. Fixes: #6002 Change-Id: I723636515193e0addc86dd0a3132bc23deadb81b
* Minor optimization to the codeFederico Caselli2021-02-181-17/+0
| | | | | | | | | * remove the c version of distill params since it's actually slower than the python one * add a function to langhelpers to check if the cextensions are active * minor cleanup to the OrderedSet implementation Change-Id: Iec3d0c3f0f42cdf51f802aaca342ba37b8783b85
* Merge "un-deprecate Oracle 2pc"mike bayer2021-02-031-1/+1
|\
| * un-deprecate Oracle 2pcMike Bayer2021-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | Oracle two-phase transactions at a rudimentary level are now no longer deprecated. After receiving support from cx_Oracle devs we can provide for basic xid + begin/prepare support with some limitations, which will work more fully in an upcoming release of cx_Oracle. Two phase "recovery" is not currently supported. Fixes: #5884 Change-Id: I961c0ad14a530acc6b069bd9bfce99fc34124abc
* | Implement per-connection logging tokenMike Bayer2021-02-031-0/+71
|/ | | | | | | | | | | | | | | Added new execution option :paramref:`_engine.Connection.execution_options.logging_token`. This option will add an additional per-message token to log messages generated by the :class:`_engine.Connection` as it executes statements. This token is not part of the logger name itself (that part can be affected using the existing :paramref:`_sa.create_engine.logging_name` parameter), so is appropriate for ad-hoc connection use without the side effect of creating many new loggers. The option can be set at the level of :class:`_engine.Connection` or :class:`_engine.Engine`. Fixes: #5911 Change-Id: Iec9c39b868b3578fcedc1c094dace5b6f64bacea
* Fix a couple of bugs in the asyncio implementationFederico Caselli2021-01-211-12/+14
| | | | | | | | | | | | | Log an informative message if a connection is not closed and the gc is reclaiming it when using an async dpapi, that does not support running IO at that stage. The ``AsyncAdaptedQueue`` used by default on async dpapis should instantiate a queue only when it's first used to avoid binding it to a possibly wrong event loop. Fixes: #5823 Change-Id: Ibfc50e209b1937ae3d6599ae7997f028c7a92c33
* Merge "Create explicit GC ordering between ConnectionFairy/ConnectionRecord"mike bayer2021-01-162-8/+14
|\
| * Create explicit GC ordering between ConnectionFairy/ConnectionRecordMike Bayer2021-01-152-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where connection pool would not return connections to the pool or otherwise be finalized upon garbage collection under pypy if the checked out connection fell out of scope without being closed. This is a long standing issue due to pypy's difference in GC behavior that does not call weakref finalizers if they are relative to another object that is also being garbage collected. A strong reference to the related record is now maintained so that the weakref has a strong-referenced "base" to trigger off of. Fixes: #5842 Change-Id: Id5448fdacb6cceaac1ea40b2fbc851f052ed8e86
* | Guard against re-entrant autobegin in Core, ORMMike Bayer2021-01-151-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed bug in "future" version of :class:`.Engine` where emitting SQL during the :meth:`.EngineEvents.do_begin` event hook would cause a re-entrant condition due to autobegin, including the recipe documented for SQLite to allow for savepoints and serializable isolation support. Fixed issue in new :class:`_orm.Session` similar to that of the :class:`_engine.Connection` where the new "autobegin" logic could be tripped into a re-entrant state if SQL were executed within the :meth:`.SessionEvents.after_transaction_create` event hook. Also repair the new "testing_engine" pytest fixture to set up for "future" engine appropriately, which wasn't working leading to the test_execute.py tests not using the future engine since recent f1e96cb0874927a475d0c11139. Fixes: #5845 Change-Id: Ib2432d8c8bd753e24be60720ec47affb2df15a4a
* | update execute() arg formats in modules and testsMike Bayer2021-01-154-82/+125
|/ | | | | | | | | | | | | continuing with producing a SQLAlchemy 1.4.0b2 that internally does not emit any of its own 2.0 deprecation warnings, migrate the *args and **kwargs passed to execute() methods that now must be a single list or dictionary. Alembic 1.5 is again waiting on this internal consistency to be present so that it can pass all tests with no 2.0 deprecation warnings. Change-Id: If6b792e57c8c5dff205419644ab68e631575a2fa
* reinvent xdist hooks in terms of pytest fixturesMike Bayer2021-01-139-234/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To allow the "connection" pytest fixture and others work correctly in conjunction with setup/teardown that expects to be external to the transaction, remove and prevent any usage of "xdist" style names that are hardcoded by pytest to run inside of fixtures, even function level ones. Instead use pytest autouse fixtures to implement our own r"setup|teardown_test(?:_class)?" methods so that we can ensure function-scoped fixtures are run within them. A new more explicit flow is set up within plugin_base and pytestplugin such that the order of setup/teardown steps, which there are now many, is fully documented and controllable. New granularity has been added to the test teardown phase to distinguish between "end of the test" when lock-holding structures on connections should be released to allow for table drops, vs. "end of the test plus its teardown steps" when we can perform final cleanup on connections and run assertions that everything is closed out. From there we can remove most of the defensive "tear down everything" logic inside of engines which for many years would frequently dispose of pools over and over again, creating for a broken and expensive connection flow. A quick test shows that running test/sql/ against a single Postgresql engine with the new approach uses 75% fewer new connections, creating 42 new connections total, vs. 164 new connections total with the previous system. As part of this, the new fixtures metadata/connection/future_connection have been integrated such that they can be combined together effectively. The fixture_session(), provide_metadata() fixtures have been improved, including that fixture_session() now strongly references sessions which are explicitly torn down before table drops occur afer a test. Major changes have been made to the ConnectionKiller such that it now features different "scopes" for testing engines and will limit its cleanup to those testing engines corresponding to end of test, end of test class, or end of test session. The system by which it tracks DBAPI connections has been reworked, is ultimately somewhat similar to how it worked before but is organized more clearly along with the proxy-tracking logic. A "testing_engine" fixture is also added that works as a pytest fixture rather than a standalone function. The connection cleanup logic should now be very robust, as we now can use the same global connection pools for the whole suite without ever disposing them, while also running a query for PostgreSQL locks remaining after every test and assert there are no open transactions leaking between tests at all. Additional steps are added that also accommodate for asyncio connections not explicitly closed, as is the case for legacy sync-style tests as well as the async tests themselves. As always, hundreds of tests are further refined to use the new fixtures where problems with loose connections were identified, largely as a result of the new PostgreSQL assertions, many more tests have moved from legacy patterns into the newest. An unfortunate discovery during the creation of this system is that autouse fixtures (as well as if they are set up by @pytest.mark.usefixtures) are not usable at our current scale with pytest 4.6.11 running under Python 2. It's unclear if this is due to the older version of pytest or how it implements itself for Python 2, as well as if the issue is CPU slowness or just large memory use, but collecting the full span of tests takes over a minute for a single process when any autouse fixtures are in place and on CI the jobs just time out after ten minutes. So at the moment this patch also reinvents a small version of "autouse" fixtures when py2k is running, which skips generating the real fixture and instead uses two global pytest fixtures (which don't seem to impact performance) to invoke the "autouse" fixtures ourselves outside of pytest. This will limit our ability to do more with fixtures until we can remove py2k support. py.test is still observed to be much slower in collection in the 4.6.11 version compared to modern 6.2 versions, so add support for new TOX_POSTGRESQL_PY2K and TOX_MYSQL_PY2K environment variables that will run the suite for fewer backends under Python 2. For Python 3 pin pytest to modern 6.2 versions where performance for collection has been improved greatly. Includes the following improvements: Fixed bug in asyncio connection pool where ``asyncio.TimeoutError`` would be raised rather than :class:`.exc.TimeoutError`. Also repaired the :paramref:`_sa.create_engine.pool_timeout` parameter set to zero when using the async engine, which previously would ignore the timeout and block rather than timing out immediately as is the behavior with regular :class:`.QueuePool`. For asyncio the connection pool will now also not interact at all with an asyncio connection whose ConnectionFairy is being garbage collected; a warning that the connection was not properly closed is emitted and the connection is discarded. Within the test suite the ConnectionKiller is now maintaining strong references to all DBAPI connections and ensuring they are released when tests end, including those whose ConnectionFairy proxies are GCed. Identified cx_Oracle.stmtcachesize as a major factor in Oracle test scalability issues, this can be reset on a per-test basis rather than setting it to zero across the board. the addition of this flag has resolved the long-standing oracle "two task" error problem. For SQL Server, changed the temp table style used by the "suite" tests to be the double-pound-sign, i.e. global, variety, which is much easier to test generically. There are already reflection tests that are more finely tuned to both styles of temp table within the mssql test suite. Additionally, added an extra step to the "dropfirst" mechanism for SQL Server that will remove all foreign key constraints first as some issues were observed when using this flag when multiple schemas had not been torn down. Identified and fixed two subtle failure modes in the engine, when commit/rollback fails in a begin() context manager, the connection is explicitly closed, and when "initialize()" fails on the first new connection of a dialect, the transactional state on that connection is still rolled back. Fixes: #5826 Fixes: #5827 Change-Id: Ib1d05cb8c7cf84f9a4bfd23df397dc23c9329bfe
* remove more bound metadataMike Bayer2021-01-052-26/+72
| | | | | | | | | | | | | | in Iae6ab95938a7e92b6d42086aec534af27b5577d3 I missed that the "bind" was being stuck onto the MetaData in TablesTest, which led thousands of ORM tests to still use bound metadata. Keep looking for bound metadata. standardize all ORM tests on a single means of getting a Session when the Session API isn't the thing we are directly testing, using a new function fixture_session() that replaces create_session() and uses modern defaults. Change-Id: Iaf71206e9ee568151496d8bc213a069504bf65ef
* remove metadata.bind use from test suiteMike Bayer2021-01-034-621/+498
| | | | | | | | | | | | | | importantly this means we can remove bound metadata from the fixtures that are used by Alembic's test suite. hopefully this is the last one that has to happen to allow Alembic to be fully 1.4/2.0. Start moving from @testing.provide_metadata to a pytest metadata fixture. This does not seem to have any negative effects even though TablesTest uses a "self.metadata" attribute. Change-Id: Iae6ab95938a7e92b6d42086aec534af27b5577d3
* Cache asyngpg prepared statementsMike Bayer2021-01-021-0/+7
| | | | | | | | | | | | | | | | | Enhanced the performance of the asyncpg dialect by caching the asyncpg PreparedStatement objects on a per-connection basis. For a test case that makes use of the same statement on a set of pooled connections this appears to grant a 10-20% speed improvement. The cache size is adjustable and may also be disabled. Unfortunately the caching gets more complicated when there are schema changes present. An invalidation scheme is now also added to accommodate for prepared statements as well as asyncpg cached OIDs. However, the exception raises cannot be prevented if DDL has changed database structures that were cached for a particular asyncpg connection. Logic is added to clear the caches when these errors occur. Change-Id: Icf02aa4871eb192f245690f28be4e9f9c35656c6
* Emit deprecation warning for general DDLElement.bind argumentMike Bayer2020-12-141-1/+1
| | | | Change-Id: I8ab1fd98340cb30aa43075508b3a0b9feffa290c
* Emit 2.0 deprecation warning for sub-transactionsMike Bayer2020-12-142-270/+352
| | | | | | | | The nesting pattern will be removed in 2.0, so the use of the MarkerTransaction should emit a 2.0 deprecation warning unconditionally. Change-Id: I96aed22c4e5db9b59e9b28a7f2d1283cd99a9cb6
* Merge "correct for "autocommit" deprecation warning"mike bayer2020-12-117-398/+504
|\
| * correct for "autocommit" deprecation warningMike Bayer2020-12-117-398/+504
| | | | | | | | | | | | | | | | | | | | | | | | Ensure no autocommit warnings occur internally or within tests. Also includes fixes for SQL Server full text tests which apparently have not been working at all for a long time, as it used long removed APIs. CI has not had fulltext running for some years and is now installed. Change-Id: Id806e1856c9da9f0a9eac88cebc7a94ecc95eb96
* | add aiomysql supportMike Bayer2020-12-101-141/+140
| | | | | | | | | | | | | | | | | | This is a re-gerrit of the original gerrit merged in Ia8ad3efe3b50ce75a3bed1e020e1b82acb5f2eda Reverted due to ongoing issues. Fixes: #5747 Change-Id: I2b57e76b817eed8f89457a2146b523a1cab656a8
* | Revert "Merge "add aiomysql support""Mike Bayer2020-12-091-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 23343f87f3297ad31d7315ac0e5312db10ef7592, reversing changes made to c5831b1abd98c46ef7eab7ee82ead18756aea112. The crashes that occur in jenkins have not been solved and are now impacting master. I am not able to reproduce the failure, including running on the CI machines directly, and a few runs where I sat there for 20 minutes and watched, it didn't happen. it is the ultimate heisenbug. Additionally, there's a reference to "arraysize" that doesn't exist in fetchmany() and there seem to be no tests that exercise this for any DBAPI which is also a major bug to be fixed. References: #5747
* | add aiomysql supportMike Bayer2020-12-081-0/+1
|/ | | | | Fixes: #5747 Change-Id: Ia8ad3efe3b50ce75a3bed1e020e1b82acb5f2eda
* QueuePool: support subsecond timeoutJordan Pittier2020-11-211-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes: #5719 <!-- Provide a general summary of your proposed changes in the Title field above --> ### Description Make it explicit in the documentation and in the default value for the 'timeout' parameter that `timeout` can be a float. Because Python timing is not very accurate, warn about the precision. ### Checklist <!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once) --> This pull request is: - [ ] A documentation / typographical error fix - Good to go, no issue or tests are needed - [x] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [ ] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. **Have a nice day!** Closes: #5710 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5710 Pull-request-sha: 5f4eef8b4aba756d32e14ea41f71ef2919c26b84 Change-Id: I462524b1624ca5cc76d083a1d58e5dc89501c1a9
* Merge "Support pool.connect() event firing before all else"mike bayer2020-11-202-0/+125
|\
| * Support pool.connect() event firing before all elseMike Bayer2020-11-192-0/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where a connection pool event specified with a keyword, most notably ``insert=True``, would be lost when the event were set up. This would prevent startup events that need to fire before dialect-level events from working correctly. The internal mechanics of the engine connection routine has been altered such that it's now guaranteed that a user-defined event handler for the :meth:`_pool.PoolEvents.connect` handler, when established using ``insert=True``, will allow an event handler to run that is definitely invoked **before** any dialect-specific initialization starts up, most notably when it does things like detect default schema name. Previously, this would occur in most cases but not unconditionally. A new example is added to the schema documentation illustrating how to establish the "default schema name" within an on-connect event (upcoming as part of I882edd5bbe06ee5b4d0a9c148854a57b2bcd4741) Addiional changes to support setting default schema name: The Oracle dialect now uses ``select sys_context( 'userenv', 'current_schema' ) from dual`` to get the default schema name, rather than ``SELECT USER FROM DUAL``, to accommodate for changes to the session-local schema name under Oracle. Added a read/write ``.autocommit`` attribute to the DBAPI-adaptation layer for the asyncpg dialect. This so that when working with DBAPI-specific schemes that need to use "autocommit" directly with the DBAPI connection, the same ``.autocommit`` attribute which works with both psycopg2 as well as pg8000 is available. Fixes: #5716 Fixes: #5708 Change-Id: I7dce56b4345ffc720e25e2aaccb7e42bb29e5671
* | Allow MetaData as the target for column_reflect eventMike Bayer2020-11-181-0/+36
|/ | | | | | | | | The :meth:`_event.DDLEvents.column_reflect` event may now be applied to a :class:`_schema.MetaData` object where it will take effect for the :class:`_schema.Table` objects local to that collection. Fixes: #5712 Change-Id: I6044baa72d096ebd1fd99128270119747d1461b9
* Merge "Convert to autoload_with internally"mike bayer2020-11-081-101/+98
|\
| * Convert to autoload_with internallyMike Bayer2020-11-071-101/+98
| | | | | | | | | | | | | | | | | | Fixed bug where the now-deprecated ``autoload`` parameter was being called internally within the reflection routines when a related table were reflected. Fixes: #5684 Change-Id: I6ab439a2f49ff1ae2d3c7a15b531cbafbc3cf594
* | Support "sqlalchemy.future" for engine_from_configMike Bayer2020-11-061-0/+24
|/ | | | | | | | | Added the "future" keyword to the list of words that are known by the :func:`_sa.engine_from_config` function, so that the values "true" and "false" may be configured as "boolean" values when using a key such as ``sqlalchemy.future = true`` or ``sqlalchemy.future = false``. Change-Id: Ib4bba748497cc68e4c913dde54c23a4bb08b4deb
* Deprecate bind args, execute() methods that were missedMike Bayer2020-10-303-189/+225
| | | | | | in particular text(bind), DDL.execute(). Change-Id: Ie85ae9f61219182f5649f68e5f52b4923843199c
* Add FAQ entry for retry subject; recipe w/ autocommitMike Bayer2020-10-191-0/+181
| | | | | | | | | | | | | | | | | In order to invalidate a connection within a Transaction block and an execution context, we need to take advantage of the simpler transaction design added in 1.4. The recipe can be done on 1.3 but it requires a lot more hacking and isn't worth it. Clearly since the recipe is part of the tests now we can in the future consider adding a feature that's built in for this case but it would have to absolutely guarantee the DBAPI is in autocommit mode and also prevent any "write" operations from taking place. Recipe for now. Fixes: #5657 Change-Id: Ia9ea8cced084d154e83e4d1c259e080b776ec38a
* Merge "Add deprecation for base Executable.bind"mike bayer2020-10-172-8/+8
|\
| * Add deprecation for base Executable.bindMike Bayer2020-10-162-8/+8
| | | | | | | | | | | | | | | | | | | | These attributes will be removed in SQLAlchemy 2.0. Also alters the deprecation message to qualify the type of object correctly. this in turn requires changes in the warnings filter and deprecation tests. Change-Id: I5779d9813e88f42e5db0c7b5e3ffff1d1535c203
* | Genericize setinputsizes and support pyodbcMike Bayer2020-10-161-0/+221
|/ | | | | | | | | | | | Reworked the "setinputsizes()" set of dialect hooks to be correctly extensible for any arbirary DBAPI, by allowing dialects individual hooks that may invoke cursor.setinputsizes() in the appropriate style for that DBAPI. In particular this is intended to support pyodbc's style of usage which is fundamentally different from that of cx_Oracle. Added support for pyodbc. Fixes: #5649 Change-Id: I9f1794f8368bf3663a286932cfe3992dae244a10
* Revert "Use monotonic time for pool age measurement"Mike Bayer2020-10-072-9/+1
| | | | | | | | | | This reverts commit 0220b58917b5a979891b5765f6ac5095e0368489. I completely misread https://www.python.org/dev/peps/pep-0418/#rationale and the accuracy of monotonic() is *worse* on windows than time.time(), which is bizarre. Change-Id: I2d571e268a2051bea68736507773d3904403af9e
* force a sleep for test_reconnectMike Bayer2020-10-071-0/+3
| | | | | | | | | | | as I dont have a windows machine to test I don't really know how to get a millisecond-accurate timer for windows, Python documentation claimed time.monotonic() did this however the continued failure of test_reconnect indicates this is not the case and that the timer is still bumping up by multi-millisecond granularity. force a delay instead. Change-Id: I237b223eabc55c1d47ecece13873be1f7be20e47
* Use monotonic time for pool age measurementMike Bayer2020-10-072-1/+12
| | | | | | | | | | | | | The internal clock used by the :class:`_pool.Pool` object is now time.monotonic_time() under Python 3. Under Python 2, time.time() is still used, which is legacy. This clock is used to measure the age of a connection against its starttime, and used in comparisons against the pool_timeout setting as well as the last time the pool was marked as invalid to determine if the connection should be recycled. Previously, time.time() was used which was subject to inaccuracies as a result of system clock changes as well as poor time resolution on windows. Change-Id: I94f90044c1809508e26a5a00134981c2a00d0405
* add --notimingintensive; block from github jobsMike Bayer2020-10-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | this provides a front-end option to disable tests marked as timing_intensive, all of which are in test_pool, which are more fragile and aren't consistent on the github runners. also remove /reduce unnecessary time.sleep() from two other pool tests that are not timing intensive. note that this removes test_hanging_connect_within_overflow from the github runs via the timing_intensive requirement. I've also removed MockReconnectTest from exclusions as those are really important tests and they use mocks so should not have platform dependent issues. Need to see what the windows failures are. Closes: #5633 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5633 Pull-request-sha: 166833e16ec342dfa10edb287d7aa495ddd1b59d Change-Id: Icb3d284a2a952e2495d80fa91e22e0b32a54340f
View Lorry Controller Status