summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/engine
Commit message (Collapse)AuthorAgeFilesLines
* happy new year 2023Mike Bayer2023-01-0314-14/+14
| | | | Change-Id: I14db8e9c69a832b0f5dae8036db3c0a70bb49edd
* Merge "look out for extras=None in freeze" into rel_1_4mike bayer2022-12-091-1/+1
|\
| * look out for extras=None in freezeMike Bayer2022-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | Fixed issue where :meth:`_engine.Result.freeze` method would not work for textual SQL using either :func:`_sql.text` or :meth:`_engine.Connection.exec_driver_sql`. Fixes: #8963 Change-Id: Ia131c6ac41a4adf32eb1bf1abf23930ef395f16c (cherry picked from commit 44170aee47a021883c6244f702de2e4385a5cd1d)
* | Better syncronize async result docs with plain ones.Federico Caselli2022-12-091-133/+146
|/ | | | | | | | | | | Removed non-functional method ``merge`` from :class:`_asyncio.AsyncResult`. This method was non-functional and non-testes since the first introduction of asyncio in SQLAlchemy. Fixes: #7158 Fixes: #8952 Change-Id: Ibc3d17be8a8b7cab9bf2074f0408f74b4c4b161d (cherry picked from commit ab8a21c613fb6c69b07f053e4622a4426b2e9ef0)
* Add recommendation for URL.create() re: escapingGord Thompson2022-11-271-9/+15
| | | | | | | | | | | | Let users know that URL.create() can build the whole connection URL instead of making them escape things like passwords ad-hoc. includes some general cleanup of URL docstring by mike Change-Id: Ic71bb0201fecf30e1db11e006c269f2d041b5439 (cherry picked from commit 14c73685ba909838fb90d762d465e7ae8d067c15)
* soft close cursor for Query direct iterator interruptedMike Bayer2022-11-031-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where the underlying DBAPI cursor would not be closed when using :class:`_orm.Query` and direct iteration, if a user-defined exception case were raised within the iteration process, interrupting the iterator which otherwise is not possible to re-use in this context. When using :meth:`_orm.Query.yield_per` to create server-side cursors, this would lead to the usual MySQL-related issues with server side cursors out of sync. To resolve, a catch for ``GeneratorExit`` is applied within the default iterator, which applies only in those cases where the interpreter is calling ``.close()`` on the iterator in any case. A similar scenario can occur when using :term:`2.x` executions with direct use of :class:`.Result`, in that case the end-user code has access to the :class:`.Result` itself and should call :meth:`.Result.close` directly. Version 2.0 will feature context-manager calling patterns to address this use case. However within the 1.4 scope, ensured that ``.close()`` methods are available on all :class:`.Result` implementations including :class:`.ScalarResult`, :class:`.MappingResult`. Fixes: #8710 Change-Id: I3166328bfd3900957eb33cbf1061d0495c9df670
* ensure pool.reset event always called for resetMike Bayer2022-10-302-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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)
* break out text() from TextualSelect for col matchingMike Bayer2022-09-192-5/+20
| | | | | | | | | | | 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)
* change verbiage stating exact compliance with RFC-1738Mike Bayer2022-09-171-14/+21
| | | | | | | | | | | | | | | As long as we aren't using urlparse() to parse URLs, we are not RFC-1738 compliant. As we accept underscores in the scheme and not dashes or dots, we are not RFC-1738 compliant, so emulate language like that of PostgreSQL [1] that we "generally follow" this scheme but include some exceptions. [1] https://www.postgresql.org/docs/current/libpq-connect.html#id-1.7.3.8.3.6 Fixes: #8519 Change-Id: I2d7e55d9df17aed122cebb2c4c315f56c06a3da5 (cherry picked from commit c88bb2167b1c4b39c7f9378b621bb8d429269d90)
* integrate connection.terminate() for supporting dialectsMike Bayer2022-08-232-0/+21
| | | | | | | | | | | | | Integrated support for asyncpg's ``terminate()`` method call for cases where the connection pool is recycling a possibly timed-out connection, where a connection is being garbage collected that wasn't gracefully closed, as well as when the connection has been invalidated. This allows asyncpg to abandon the connection without waiting for a response that may incur long timeouts. Fixes: #8419 Change-Id: Ia575af779d5733b483a72dff3690b8bbbad2bb05 (cherry picked from commit 3b7e621aa728d9b01dbac4150e13ea2ef6af35a3)
* fix up SAVEPOINT docsMike Bayer2022-08-021-1/+1
| | | | | | | | | | | | these contained a factual error that the entire session is expired, which is no longer the case (I can't find exactly when this was changed). Additionally, added a PostgreSQL specific example w/ IntegrityError as this is the most common case for this. Tried to tighten up other language and make it as clear as possible. Change-Id: I39160e7443964db59d1d5a2e0616084767813eea (cherry picked from commit 37b8c5e755cefd9ae0fdf6816dae09b519be3b06)
* Update to flake8 5.Federico Caselli2022-07-313-4/+8
| | | | | Change-Id: I5a241a70efba68bcea9819ddce6aebc25703e68d (cherry picked from commit f8c4dba4e9f130c18ce00597c036bc26ae7abf90)
* link to main isolation level documentMike Bayer2022-07-131-13/+1
| | | | | | | this was already in 2.0. a few more corrections coming Change-Id: Id94eee9081fd5174bad2275f544010e7cb467454 references: #8252
* repair yield_per for non-SS dialects and add new optionsMike Bayer2022-07-015-25/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implemented new :paramref:`_engine.Connection.execution_options.yield_per` execution option for :class:`_engine.Connection` in Core, to mirror that of the same :ref:`yield_per <orm_queryguide_yield_per>` option available in the ORM. The option sets both the :paramref:`_engine.Connection.execution_options.stream_results` option at the same time as invoking :meth:`_engine.Result.yield_per`, to provide the most common streaming result configuration which also mirrors that of the ORM use case in its usage pattern. Fixed bug in :class:`_engine.Result` where the usage of a buffered result strategy would not be used if the dialect in use did not support an explicit "server side cursor" setting, when using :paramref:`_engine.Connection.execution_options.stream_results`. This is in error as DBAPIs such as that of SQLite and Oracle already use a non-buffered result fetching scheme, which still benefits from usage of partial result fetching. The "buffered" strategy is now used in all cases where :paramref:`_engine.Connection.execution_options.stream_results` is set. Added :meth:`.FilterResult.yield_per` so that result implementations such as :class:`.MappingResult`, :class:`.ScalarResult` and :class:`.AsyncResult` have access to this method. Fixes: #8199 Change-Id: I6dde3cbe483a1bf81e945561b60f4b7d1c434750 (cherry picked from commit e5a0cdb2eaa1d7f381e93d0529a7f8e6d5888877)
* add more cross-linking / notes for yield_per, partitionsMike Bayer2022-06-301-0/+20
| | | | | | Change-Id: I0f8db2532827c76a2751186638d22104230db843 references: #8198 (cherry picked from commit 59bafe0fbefe16269c72ac39e699e4127d49841f)
* restore parameter escaping for public methodsMike Bayer2022-06-091-1/+3
| | | | | | | | | | | | | | | 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 "graceful degrade for FKs not reflectable" into rel_1_4mike bayer2022-06-081-1/+11
|\
| * graceful degrade for FKs not reflectableMike Bayer2022-06-071-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-072-8/+2
|/ | | | | | | | other org changes and some sections from old tutorial ported to new tutorial. Change-Id: Ic0fba60ec82fff481890887beef9ed0fa271875a (Cherry-picked and independently modified)
* move bindparam quote application from compiler to defaultMike Bayer2022-05-291-12/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* adjust log stacklevel for py3.11.0b1; enable greenletMike Bayer2022-05-151-4/+4
| | | | | | | | | | | | | | | | | Fixed issue where support for logging "stacklevel" implemented in :ticket:`7612` required adjustment to work with recently released Python 3.11.0b1, also repairs the unit tests which tested this feature. Install greenlet from a py311 compat patch. re: the stacklevel thing, this is going to be very inconvenient if we have to keep hardcoding numbers everywhere for every new python version Change-Id: I0c8f7293e98c0ca5cc544538284bfd1d3020cb1f References: https://github.com/python-greenlet/greenlet/issues/288 Fixes: #8019 (cherry picked from commit 43ff5b82dc0d91cacd625ac8943622ab340958c5)
* warn for result.columns() methodMike Bayer2022-04-211-0/+9
| | | | | | | | | | | | A warning is emitted when calling upon the :meth:`.Result.columns` method with only one index, in particular ORM related cases, indicating that the current behavior of :meth:`.Result.columns` is broken in this case and will be changed in 2.0. To receive a collection of scalar values, use the :meth:`.Result.scalars` method. Fixes: #7953 Change-Id: I3c4ca3eecc2bfc85ad1c38000e5990d6dde80d22 (cherry picked from commit fe2045fb1c767436ed1e32359fe005dabead504a)
* update flake8 noqa skips with proper syntaxFederico Caselli2022-04-111-1/+1
| | | | | Change-Id: I42ed77f559e3ee5b8c600d98457ee37803ef0ea6 (cherry picked from commit 139c6ec0fb1f930be9b64545262d2580f6cbc83e)
* add close=False parameter to engine.dispose()Mike Bayer2022-03-311-17/+30
| | | | | | | | | | | | Added new parameter :paramref:`.Engine.dispose.close`, defaulting to True. When False, the engine disposal does not touch the connections in the old pool at all, simply dropping the pool and replacing it. This use case is so that when the original pool is transferred from a parent process, the parent process may continue to use those connections. Fixes: #7877 Change-Id: I88b0808442381ba5e50674787cdb64f0e77d8b54 (cherry picked from commit 87a0f7183de4e8454483c7348bf486265bfe1c4d)
* more autocommit messagingMike Bayer2022-03-241-8/+19
| | | | | | | | | | | | | Further clarified connection-level logging to indicate the BEGIN, ROLLBACK and COMMIT log messages do not actually indicate a real transaction when the AUTOCOMMIT isolation level is in use; messaging has been extended to include the BEGIN message itself, and the messaging has also been fixed to accommodate when the :class:`.Engine` level :paramref:`.create_engine.isolation_level` parameter was used directly. Fixes: #7853 Change-Id: Iafc78070737ad117f84262e4bde84b81a81e4ea1 (cherry picked from commit 56366924673f88e51c74d94058c11132a057ecfa)
* improve error raise for dialect/pool events w/ async engineMike Bayer2022-03-021-1/+7
| | | | | | | | | Fixed issues where a descriptive error message was not raised for some classes of event listening with an async engine, which should instead be a sync engine instance. Change-Id: I00b9f4fe9373ef5fd5464fac10651cc4024f648e (cherry picked from commit e893ce1196a1fb02ad53576fd75ffd40e5d9dd89)
* remove never-used get_result_cursor_strategy() methodMike Bayer2022-02-191-67/+0
| | | | | | | | | | | | | | This method I would assume got committed during the 1.4 engine refactor, where we moved from different kinds of ResultProxy implementations to different strategy classes instead. These strategies are set up by dialects by setting "self.cursor_fetch_strategy" in the execution context. The method here was likely a previous iteration of that which got merged but was never used. Change-Id: Iec292428f41c2c245bf7ae78beaa14786c28846c (cherry picked from commit ec4a4910aa9ecc516cf3b096cb053fd9be7f82cc)
* updates for mariadb connector 1.0.10Mike Bayer2022-02-191-1/+0
| | | | | | | | | | | | | | | Fixed regression in mariadbconnector dialect as of mariadb connector 1.0.10 where the DBAPI no longer pre-buffers cursor.lastrowid. The dialect now fetches this value proactively for situations where it applies. test_invalidate_on_results seems to pass for mariadbconnector now. the driver has likely changed how it buffers result sets. This is a major change for them to make in a point release so we might want to watch this in case they reverse course again. Fixes: #7738 Change-Id: I9610aae01d1ae42fa92ffbc7123a6948e40ec9dd (cherry picked from commit e120837b682a3a822c2dff136ad48b1ca9fb6ce2)
* Accommodate escaped_bind_names for defaults/insert paramsMike Bayer2022-02-081-3/+2
| | | | | | | | | | | Fixed issue in Oracle dialect where using a column name that requires quoting when written as a bound parameter, such as ``"_id"``, would not correctly track a Python generated default value due to the bound-parameter rewriting missing this value, causing an Oracle error to be raised. Fixes: #7676 Change-Id: I5a54426d24f2f9b336e3597d5595fb3e031aad97 (cherry picked from commit c2aa6374f3965c28aa2d56cbddf6dab3e1de18a2)
* ensure exception raised for all stream w/ sync resultMike Bayer2022-02-042-0/+2
| | | | | | | | | | | | | | | | | Fixed issue where the :meth:`_asyncio.AsyncSession.execute` method failed to raise an informative exception if the ``stream_results`` execution option were used, which is incompatible with a sync-style :class:`_result.Result` object. An exception is now raised in this scenario in the same way one is already raised when using ``stream_results`` in conjunction with the :meth:`_asyncio.AsyncConnection.execute` method. Additionally, for improved stability with state-sensitive dialects such as asyncmy, the cursor is now closed when this error condition is raised; previously with the asyncmy dialect, the connection would go into an invalid state with unconsumed server side results remaining. Fixes: #7667 Change-Id: I6eb7affe08584889b57423a90258295f8b7085dc (cherry picked from commit faa9ef2cff53bde291df5ac3b5c4ed8f665ecd8c)
* Fix up Python logging metadataMarkus Gerstel2022-01-271-0/+6
| | | | | | | | | | | | | | | | | | Adjusted the logging for key SQLAlchemy components including :class:`_engine.Engine`, :class:`_engine.Connection` to establish an appropriate stack level parameter, so that the Python logging tokens ``funcName`` and ``lineno`` when used in custom logging formatters will report the correct information, which can be useful when filtering log output; supported on Python 3.8 and above. Pull request courtesy Markus Gerstel. Fixes: #7612 Closes: #7615 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7615 Pull-request-sha: cf9567beb06680df320cb12dde1f15baa68e1eb5 Change-Id: Iff23c92ef3453ac93cbd0d190e7efbf8ea4457a2 (cherry picked from commit f24a34140f6007cada900a8ae5ed03fe40ce2631)
* Add AdaptedConnection.run_asyncMike Bayer2022-01-191-0/+30
| | | | | | | | | | | | | | | | Added new method :meth:`.AdaptedConnection.run_async` to the DBAPI connection interface used by asyncio drivers, which allows methods to be called against the underlying "driver" connection directly within a sync-style function where the ``await`` keyword can't be used, such as within SQLAlchemy event handler functions. The method is analogous to the :meth:`_asyncio.AsyncConnection.run_sync` method which translates async-style calls to sync-style. The method is useful for things like connection-pool on-connect handlers that need to invoke awaitable methods on the driver connection when it's first created. Fixes: #7580 Change-Id: I03c98a72bda0234deb19c00095b31a36f19bf36d (cherry picked from commit 09ad975505adb2118f229cb5b1a75c2c412420ae)
* happy new year 2022Mike Bayer2022-01-0614-14/+14
| | | | Change-Id: Ic38dbc640aa0fe8a784a5b5e57c45a41eb0ea01b
* Merge "implement correct errors for Row immutability" into rel_1_4mike bayer2021-12-121-13/+24
|\
| * implement correct errors for Row immutabilityMike Bayer2021-12-091-13/+24
| | | | | | | | | | | | | | | | | | | | | | Corrected the error message for the ``AttributeError`` that's raised when attempting to write to an attribute on the :class:`_result.Row` class, which is immutable. The previous message claimed the column didn't exist which is misleading. Fixes: #7432 Change-Id: If0e2cbd3f763dca6c99a18aa42252c69f1207d59 (cherry picked from commit f113e979219e20a22044c4b262e4531ba9993b8a)
* | check for string_types, not str, for py2 supportMike Bayer2021-12-121-1/+1
|/ | | | | | | | | Fixed regression in the :func:`_engine.make_url` function used to parse URL strings where the query string parsing would go into a recursion overflow if a Python 2 ``u''`` string were used. Fixes: #7446 Change-Id: I081275673e6240a52f71da7dfaaf04e6fe32cf48
* Merge "Warn when caching is disabled / document" into rel_1_4mike bayer2021-12-071-4/+17
|\
| * Warn when caching is disabled / documentMike Bayer2021-12-061-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | Merge "contextmanager skips rollback if trans says to skip it" into rel_1_4mike bayer2021-12-072-2/+28
|\ \
| * | contextmanager skips rollback if trans says to skip itMike Bayer2021-12-062-2/+28
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where if an exception occurred when the :class:`_orm.Session` were to close the connection within the :meth:`_orm.Session.commit` method, when using a context manager for :meth:`_orm.Session.begin` , it would attempt a rollback which would not be possible as the :class:`_orm.Session` was in between where the transaction is committed and the connection is then to be returned to the pool, raising the exception "this sessiontransaction is in the committed state". This exception can occur mostly in an asyncio context where CancelledError can be raised. Fixes: #7388 Change-Id: I1a85a3a7eae79f3553ddf1e3d245a0d90b0a2f40 (cherry picked from commit a845da8b0fc5bb172e278c399a1de9a2e49d62af)
* | Add __copy__, __deepcopy__ to URL. Fixes: #7400Tom Ritchford2021-12-061-0/+16
|/ | | | | | | | | | | | | Added support for ``copy()`` and ``deepcopy()`` to the :class:`_url.URL` class. Pull request courtesy Tom Ritchford. Fixes: #7400 Closes: #7401 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7401 Pull-request-sha: a2c1b8992f5d153c6210178cda47b8ae96b91fb5 Change-Id: I55977338b2655a7d4f733ae786d31e589185e9ca (cherry picked from commit 924cc31975f8874d369db6599575e361bdb34be9)
* Check for Mapping explicitly in 2.0 paramsMike Bayer2021-11-041-3/+3
| | | | | | | | | | | Fixed issue in future :class:`_future.Connection` object where the :meth:`_future.Connection.execute` method would not accept a non-dict mapping object, such as SQLAlchemy's own :class:`.RowMapping` or other ``abc.collections.Mapping`` object as a parameter dictionary. Fixes: #7291 Change-Id: I819f079d86d19d1d81c570e0680f987e51e34b84 (cherry picked from commit 248d232459e38561999c4172acaaddd651c1a933)
* Update "transaction has already begun" languageMike Bayer2021-11-042-3/+8
| | | | | | | | | | | | | | | | | | | | As future connections will now be autobeginning, there will be more cases where begin() can't be called as well as where isolation level can't be set, which will be surprising as this is a behavioral change for 2.0; additionally, when DBAPI autocommit is set, there isn't actually a DBAPI level transaction in effect even though Connection has a Transaction object. Clarify the language in these two error messages to make it clear that begin() and autobegin are tracking a SQLAlchemy-level Transaction() object, whether or not the DBAPI has actually started a transaction, and that this is the reason rollback() or commit() is required before performing the requsted operation. Additionally make sure the error message mentions "autobegin" as a likely reason this error is being encountered along with what Connection needs the user to do in order to resolve. Change-Id: If8763939eeabc46aa9d9209a56d05ad82b892c5c (cherry picked from commit fee0855bfe2982927ab21ce7398fa48b90af7ca4)
* ensure soft_close occurs for fetchmany with server side cursorMike Bayer2021-11-022-8/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where the :meth:`_engine.CursorResult.fetchmany` method would fail to autoclose a server-side cursor (i.e. when ``stream_results`` or ``yield_per`` is in use, either Core or ORM oriented results) when the results were fully exhausted. All :class:`_result.Result` objects will now consistently raise :class:`_exc.ResourceClosedError` if they are used after a hard close, which includes the "hard close" that occurs after calling "single row or value" methods like :meth:`_result.Result.first` and :meth:`_result.Result.scalar`. This was already the behavior of the most common class of result objects returned for Core statement executions, i.e. those based on :class:`_engine.CursorResult`, so this behavior is not new. However, the change has been extended to properly accommodate for the ORM "filtering" result objects returned when using 2.0 style ORM queries, which would previously behave in "soft closed" style of returning empty results, or wouldn't actually "soft close" at all and would continue yielding from the underlying cursor. As part of this change, also added :meth:`_result.Result.close` to the base :class:`_result.Result` class and implemented it for the filtered result implementations that are used by the ORM, so that it is possible to call the :meth:`_engine.CursorResult.close` method on the underlying :class:`_engine.CursorResult` when the the ``yield_per`` execution option is in use to close a server side cursor before remaining ORM results have been fetched. This was again already available for Core result sets but the change makes it available for 2.0 style ORM results as well. Fixes: #7274 Change-Id: Id4acdfedbcab891582a7f8edd2e2e7d20d868e53 (cherry picked from commit 33824a9c06ca555ad208a9925bc7b40fe489fc72)
* support bind expressions w/ expanding IN; apply to psycopg2Mike Bayer2021-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Fixed issue where "expanding IN" would fail to function correctly with datatypes that use the :meth:`_types.TypeEngine.bind_expression` method, where the method would need to be applied to each element of the IN expression rather than the overall IN expression itself. Fixed issue where IN expressions against a series of array elements, as can be done with PostgreSQL, would fail to function correctly due to multiple issues within the "expanding IN" feature of SQLAlchemy Core that was standardized in version 1.4. The psycopg2 dialect now makes use of the :meth:`_types.TypeEngine.bind_expression` method with :class:`_types.ARRAY` to portably apply the correct casts to elements. The asyncpg dialect was not affected by this issue as it applies bind-level casts at the driver level rather than at the compiler level. as part of this commit the "bind translate" feature has been simplified and also applies to the names in the POSTCOMPILE tag to accommodate for brackets. Fixes: #7177 Change-Id: I08c703adb0a9bd6f5aeee5de3ff6f03cccdccdc5
* Reflect table can reflect table with no columnsSumit Khanna2021-10-141-2/+3
| | | | | | | | | | | | | | | The :meth:`_engine.Inspector.reflect_table` method now supports reflecting tables that do not have user defined columns. This allows :meth:`_schema.MetaData.reflect` to properly complete reflection on databases that contain such tables. Currently, only PostgreSQL is known to support such a construct among the common database backends. Fixes: #3247 Closes: #7118 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7118 Pull-request-sha: cb8ce01957e9a1453290a7c2728af8c60ef55fa1 Change-Id: I906cebe17d13554d79086b92f3e1e51ffba3e818
* indicate private use of URL.__new__ privately onlyMike Bayer2021-10-011-1/+3
| | | | | | | | | | | Fixed issue where the deprecation warning for the :class:`.URL` constructor which indicates that the :meth:`.URL.create` method should be used would not emit if a full positional argument list of seven arguments were passed; additionally, validation of URL arguments will now occur if the constructor is called in this way, which was being skipped previously. Fixes: #7130 Change-Id: I8c8491d8aa7774afaf67c22b4f8e9859f780f2d9
* changelog, doc editsMike Bayer2021-09-221-8/+12
| | | | Change-Id: Iafb50de7e28626d9cee755db9c05ac7189b4d963
* clarify "encoding" parameter furtherMike Bayer2021-09-201-8/+16
| | | | | | | | | 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
* Surface driver connection object when using a proxied dialectFederico Caselli2021-09-174-2/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | Improve the interface used by adapted drivers, like the asyncio ones, to access the actual connection object returned by the driver. The :class:`_engine._ConnectionRecord` and :class:`_engine._ConnectionFairy` now have two new attributes: * ``dbapi_connection`` always represents a DBAPI compatible object. For pep-249 drivers, this is the DBAPI connection as it always has been, previously accessed under the ``.connection`` attribute. For asyncio drivers that SQLAlchemy adapts into a pep-249 interface, the returned object will normally be a SQLAlchemy adaption object called :class:`_engine.AdaptedConnection`. * ``driver_connection`` always represents the actual connection object maintained by the third party pep-249 DBAPI or async driver in use. For standard pep-249 DBAPIs, this will always be the same object as that of the ``dbapi_connection``. For an asyncio driver, it will be the underlying asyncio-only connection object. The ``.connection`` attribute remains available and is now a legacy alias of ``.dbapi_connection``. Fixes: #6832 Change-Id: Ib72f97deefca96dce4e61e7c38ba430068d6a82e
View Lorry Controller Status