summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/engine
Commit message (Collapse)AuthorAgeFilesLines
* remove case_sensitive create_engine parameterMike Bayer2021-11-013-55/+2
| | | | | | | | | | | | Removed the previously deprecated ``case_sensitive`` parameter from :func:`_sa.create_engine`, which would impact only the lookup of string column names in Core-only result set rows; it had no effect on the behavior of the ORM. The effective behavior of what ``case_sensitive`` refers towards remains at its default value of ``True``, meaning that string names looked up in ``row._mapping`` will match case-sensitively, just like any other Python mapping. Change-Id: I0dc4be3fac37d30202b1603db26fa10a110b618d
* Merge "2.0 removals: LegacyRow, connectionless execution, close_with_result" ↵mike bayer2021-10-319-640/+104
|\ | | | | | | into main
| * 2.0 removals: LegacyRow, connectionless execution, close_with_resultMike Bayer2021-10-319-640/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in order to remove LegacyRow / LegacyResult, we have to also lose close_with_result, which connectionless execution relies upon. also includes a new profiles.txt file that's all against py310, as that's what CI is on now. some result counts changed by one function call which was enough to fail the low-count result tests. Replaces Connectable as the common interface between Connection and Engine with EngineEventsTarget. Engine is no longer Connectable. Connection and MockConnection still are. References: #7257 Change-Id: Iad5eba0313836d347e65490349a22b061356896a
* | Merge "Remove deprecated dialects and drivers" into mainmike bayer2021-10-312-3/+2
|\ \
| * | Remove deprecated dialects and driversFederico Caselli2021-10-312-3/+2
| |/ | | | | | | | | Fixes: #7258 Change-Id: I3577f665eca04f2632b69bcb090f0a4ec9271db9
* | The ``has_table`` method now also checks viewsFederico Caselli2021-10-312-3/+14
|/ | | | | | | | | | | | The :meth:`_engine.Inspector.has_table` method will now consistently check for views of the given name as well as tables. Previously this behavior was dialect dependent, with PostgreSQL, MySQL/MariaDB and SQLite supporting it, and Oracle and SQL Server not supporting it. Third party dialects should also seek to ensure their :meth:`_engine.Inspector.has_table` method searches for views as well as tables for the given name. Fixes: #7161 Change-Id: I9e523c76741b19596c81ef577dc6f0823e44183b
* 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
* Merge "Add scalars method to connection and session classes"mike bayer2021-09-151-0/+18
|\
| * Add scalars method to connection and session classesMiguel Grinberg2021-09-141-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added new methods :meth:`_orm.Session.scalars`, :meth:`_engine.Connection.scalars`, :meth:`_asyncio.AsyncSession.scalars` and :meth:`_asyncio.AsyncSession.stream_scalars`, which provide a short cut to the use case of receiving a row-oriented :class:`_result.Result` object and converting it to a :class:`_result.ScalarResult` object via the :meth:`_engine.Result.scalars` method, to return a list of values rather than a list of rows. The new methods are analogous to the long existing :meth:`_orm.Session.scalar` and :meth:`_engine.Connection.scalar` methods used to return a single value from the first row only. Pull request courtesy Miguel Grinberg. Fixes: #6990 Closes: #6991 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/6991 Pull-request-sha: b3e0bb3042c55b0cc5af6a25cb3f31b929f88a47 Change-Id: Ia445775e24ca964b0162c2c8e5ca67dd1e39199f
* | Ensure str is callect on the URL password.Federico Caselli2021-09-132-14/+48
|/ | | | | | | | | | | Ensure that ``str()`` is called on the an ``URL.password`` argument, allowing usage of objects that implement the ``__str__()`` method as password attributes. Also clarified that one such object is not appropriate to dynamically change the password. Fixes: #6958 Change-Id: Id0690990a64b9e0935537b7b8f5a73efe6a9e3dc
* remove erroneous None check from _assert_strMike Bayer2021-09-041-3/+0
| | | | | | | | Fixed issue in ``URL`` where validation of "drivername" would not appropriately respond to the ``None`` value where a string were expected. Fixes: #6983 Change-Id: If546c373a60533779595a9e393ea9a59a9b8a96f
* Fix and test sequences w/ executemany in pre-exec scenariosMike Bayer2021-09-021-1/+2
| | | | | | | | | | | | | | Fixed issue where an engine that had ``implicit_returning`` set to False would fail to function when PostgreSQL's "fast insertmany" feature were used in conjunction with a ``Sequence``, as well as if any kind of "executemany" with "return_defaults()" were used in conjunction with a ``Sequence``. Note that PostgreSQL "fast insertmany" uses "RETURNING" by definition, when the SQL statement is passed to the driver; overall, the ``implicit_returning`` flag is legacy and has no real use in modern SQLAlchemy, and will be deprecated in a separate change. Fixes: #6963 Change-Id: Id8e3dd50a21b9124f338067b0fdb57b8f608dca8
* Avoid mutable object as default valuestsimafeip2021-08-241-1/+1
| | | | | | | | | Fixes: #6915 Closes: #6916 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/6916 Pull-request-sha: 6ec484d3d14b7dd7053d10a5d550bd74eb524c8b Change-Id: I2c87fbed44870110e35a69ee9a9e678671eeb8f0
* Merge "restore statement substitution to before_execute()"mike bayer2021-08-231-1/+6
|\
| * restore statement substitution to before_execute()Mike Bayer2021-08-201-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where the ability of the :meth:`_engine.ConnectionEvents.before_execute` method to alter the SQL statement object passed, returning the new object to be invoked, was inadvertently removed. This behavior has been restored. The refactor in a1939719a652774a437f69f8d4788b3f08650089 removed this feature for some reason and there were no tests in place to detect it. I don't see any indication this was planned. Fixes: #6913 Change-Id: Ia77ca08aa91ab9403f19a8eb61e2a0e41aad138a
* | heads up that execute(query).first() can't apply LIMIT 1Mike Bayer2021-08-201-0/+11
|/ | | | | Fixes: #6914 Change-Id: I5de9843dd3723c017b94b705fc009b883737ede1
* Merge "Documentation improvements"mike bayer2021-07-201-0/+9
|\
| * Documentation improvementsFederico Caselli2021-07-201-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Also remove deprecated usage: - load_only does not accept strings - case.whens is positional only Ref #6712 Ref #5994 Ref #6121 Ref #6785 Ref https://groups.google.com/g/sqlalchemy/c/-cnhThEu3kk Change-Id: I5db49a075b9d3d332518b9d189a24b13b502e2af
* | labeling refactorMike Bayer2021-07-121-3/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To service #6718 and #6710, the system by which columns are given labels in a SELECT statement as well as the system that gives them keys in a .c or .selected_columns collection have been refactored to provide a single source of truth for both, in constrast to the previous approach that included similar logic repeated in slightly different ways. Main ideas: 1. ColumnElement attributes ._label, ._anon_label, ._key_label are renamed to include the letters "tq", meaning "table-qualified" - these labels are only used when rendering a SELECT that has LABEL_STYLE_TABLENAME_PLUS_COL for its label style; as this label style is primarily legacy, the "tq" names should be isolated so that in a 2.0 style application these aren't being used at all 2. The means by which the "labels" and "proxy keys" for the elements of a SELECT has been centralized to a single source of truth; previously, the three of _generate_columns_plus_names, _generate_fromclause_column_proxies, and _column_naming_convention all had duplicated rules between them, as well as that there were a little bit of labeling rules in compiler._label_select_column as well; by this we mean that the various "anon_label" "anon_key" methods on ColumnElement were called by all four of these methods, where there were many cases where it was necessary that one method comes up with the same answer as another of the methods. This has all been centralized into _generate_columns_plus_names for all the names except the "proxy key", which is generated by _column_naming_convention. 3. compiler._label_select_column has been rewritten to both not make any naming decisions nor any "proxy key" decisions, only whether to label or not to label; the _generate_columns_plus_names method gives it the information, where the proxy keys come from _column_naming_convention; previously, these proxy keys were matched based on restatement of similar (but not really the same) logic in two places. The heuristics of "whether to label or not to label" are also reorganized to be much easier to read and understand. 4. a new method compiler._label_returning_column is added for dialects to use in their "generate returning columns" methods. A github search reveals a small number of third party dialects also doing this using the prior _label_select_column method so we try to make sure _label_select_column continues to work the exact same way for that specific use case; for the "SELECT" use case it now needs 5. After some attempts to do it different ways, for the case where _proxy_key is giving us some kind of anon label, we are hard changing it to "_no_label" right now, as there's not currently a way to fully match anonymized labels from stmt.c or stmt.selected_columns to what will be in the result map. The idea of "_no_label" is to encourage the user to use label('name') for columns they want to be able to target by string name that don't have a natural name. Change-Id: I7a92a66f3a7e459ccf32587ac0a3c306650daf11
* Replace all http:// links to https://Federico Caselli2021-07-0414-17/+18
| | | | | | Also replace http://pypi.python.org/pypi with https://pypi.org/project Change-Id: I84b5005c39969a82140706472989f2a30b0c7685
* Fix typo in _warn_for_legacy_exec_formatgordthompson2021-06-241-1/+1
| | | | Change-Id: Idc24b5ab4b5a25fcfb7115c5d7be4c2ece520674
* Add Executable to DefaultGeneratorMike Bayer2021-06-231-1/+1
| | | | | | | | | | | | | | Fixed the class hierarchy for the :class:`_schema.Sequence` and the more general :class:`_schema.DefaultGenerator` base, as these are "executable" as statements they need to include :class:`_sql.Executable` in their hierarchy, not just :class:`_roles.StatementRole` as was applied arbitrarily to :class:`_schema.Sequence` previously. The fix allows :class:`_schema.Sequence` to work in all ``.execute()`` methods including with :meth:`_orm.Session.execute` which was not working in the case that a ``do_orm_execute()`` handler was also established. Fixes: #6668 Change-Id: I0d192258c7cbd1bce2552f9e748e8fdd680dc45f
* Export deferred columns but not col props; fix CTE labelingMike Bayer2021-06-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refined the behavior of ORM subquery rendering with regards to deferred columns and column properties to be more compatible with that of 1.3 while also providing for 1.4's newer features. As a subquery in 1.4 does not make use of loader options, including :func:`_orm.deferred`, a subquery that is against an ORM entity with deferred attributes will now render those deferred attributes that refer directly to mapped table columns, as these are needed in the outer SELECT if that outer SELECT makes use of these columns; however a deferred attribute that refers to a composed SQL expression as we normally do with :func:`_orm.column_property` will not be part of the subquery, as these can be selected explicitly if needed in the subquery. If the entity is being SELECTed from this subquery, the column expression can still render on "the outside" in terms of the derived subquery columns. This produces essentially the same behavior as when working with 1.3. However in this case the fix has to also make sure that the ``.selected_columns`` collection of an ORM-enabled :func:`_sql.select` also follows these rules, which in particular allows recursive CTEs to render correctly in this scenario, which were previously failing to render correctly due to this issue. As part of this change the _exported_columns_iterator() method has been removed and logic simplified to use ._all_selected_columns from any SelectBase object where _exported_columns_iterator() was used before. Additionally sets up UpdateBase to include ReturnsRows in its hierarchy; the literal point of ReturnsRows was to be a common base for UpdateBase and SelectBase so it was kind of weird it wasn't there. Fixes: #6661 Fixed issue in CTE constructs mostly relevant to ORM use cases where a recursive CTE against "anonymous" labels such as those seen in ORM ``column_property()`` mappings would render in the ``WITH RECURSIVE xyz(...)`` section as their raw internal label and not a cleanly anonymized name. Fixes: #6663 Change-Id: I26219d4d8e6c0915b641426e9885540f74fae4d2
* Merge "restore adapter logic in ORM loading"mike bayer2021-06-081-0/+4
|\
| * restore adapter logic in ORM loadingMike Bayer2021-06-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression involving how the ORM would resolve a given mapped column to a result row, where under cases such as joined eager loading, a slightly more expensive "fallback" could take place to set up this resolution due to some logic that was removed since 1.3. The issue could also cause deprecation warnings involving column resolution to be emitted when using a 1.4 style query with joined eager loading. In order to ensure we don't look up columns by string name in the ORM, we've turned on future_result=True in all cases, which I thought was already the assumption here, but apparently not. That in turn led to the issue that Session autocommit relies on close_with_result=True, which is legacy result only. This was also hard to figure out. So a new exception is raised if one tries to use future_result=True along with close_with_result, and the Session now has an explicit path for "autocommit" that sets these flags to their legacy values. This does leave the possibility of some of these fallback cases emitting warnings for users using session in autocommit along with joined inheritance and column properties, as this patch identifies that joined inheritance + column properties produce the fallback logic when looking up in the result via the adapted column, which in those tests is actually a Label object that doesn't adapt nicely. Fixes: #6596 Change-Id: I107a47e873ae05ab50853bb00a9ea0e1a88d5aee
* | Add asyncio.TimeoutError as an exit exceptionMike Bayer2021-06-071-2/+1
|/ | | | | | | | | | | | Added ``asyncio.exceptions.TimeoutError``, ``asyncio.exceptions.CancelledError`` as so-called "exit exceptions", a class of exceptions that include things like ``GreenletExit`` and ``KeyboardInterrupt``, which are considered to be events that warrant considering a DBAPI connection to be in an unusable state where it should be recycled. Fixes: #6592 Change-Id: Idcfa7aaa2d7660838b907388db9c6457afa6edbd
* Pass URL object, not the string, to on_connect_urlMike Bayer2021-06-061-2/+1
| | | | | | | | | | | | 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
* URL parsing fixesMike Bayer2021-05-241-22/+17
| | | | | | | | | | | | | Fixed a long-standing issue with :class:`.URL` where query parameters following the question mark would not be parsed correctly if the URL did not contain a database portion with a backslash. Fixed issue where an ``@`` sign in the database portion of a URL would not be interpreted correctly if the URL also had a username:password section. Fixes: #6329 Fixes: #6482 Change-Id: I6cb6478affa49b618335b947a74e64090657a98c
* Remove pep484 type comments from the codeFederico Caselli2021-05-163-39/+14
| | | | | | | | | | | | | Current effort is around the stub package, and having typing in two places makes thing worse, since the types here are usually outdated compared to the version in the stubs. Once v2 gets under way we can start consolidating the types here. Fixes: #6461 Change-Id: I7132a444bd7138123074bf5bc664b4bb119a85ce
* reformat URL attributesMike Bayer2021-05-121-11/+11
| | | | | | | | | these were using :var: which seems to not work now, not sure if this broke due to sphinx 1.4 or if this was broken anyway, but these are not even refs that can be picked up by zzzeeksphinx now. Change-Id: I24ae968ae5d870ec949b2b07dbad2afa6969a189
* Fix documentation type in URL classFederico Caselli2021-05-121-1/+1
| | | | Change-Id: I16a24718ee322efeffbf5a268d995ff53c23b696
* Update black flak8 and zimportsFederico Caselli2021-05-121-2/+4
| | | | Change-Id: I488c9557eda390e4a88319affd4c8813ee274f80
* Merge "unify transactional context managers"mike bayer2021-05-062-21/+104
|\
| * unify transactional context managersMike Bayer2021-05-052-21/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Establish deprecation path for CursorResult.keys()"mike bayer2021-05-051-1/+16
|\ \
| * | Establish deprecation path for CursorResult.keys()Mike Bayer2021-05-041-1/+16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Established a deprecation path for calling upon the :meth:`_cursor.CursorResult.keys` method for a statement that returns no rows to provide support for legacy patterns used by the "records" package as well as any other non-migrated applications. Previously, this would raise :class:`.ResourceClosedException` unconditionally in the same way as it does when attempting to fetch rows. While this is the correct behavior going forward, the :class:`_cursor.LegacyCursorResult` object will now in this case return an empty list for ``.keys()`` as it did in 1.3, while also emitting a 2.0 deprecation warning. The :class:`_cursor.CursorResult`, used when using a 2.0-style "future" engine, will continue to raise as it does now. Fixes: #6427 Change-Id: I4148f28c88039e4141deeab28b1a5994e6d6e098
* | Restore detached object logic for dynamic, but warnMike Bayer2021-05-041-1/+8
|/ | | | | | | | | | | | Fixed regression involving ``lazy='dynamic'`` loader in conjunction with a detached object. The previous behavior was that the dynamic loader upon calling methods like ``.all()`` returns empty lists for detached objects without error, this has been restored; however a warning is now emitted as this is not the correct result. Other dynamic loader scenarios correctly raise ``DetachedInstanceError``. Fixes: #6426 Change-Id: Id7ad204bef947491fa7e462c5acda2055fada910
* restore legacy begin_nested()->root transaction behaviorMike Bayer2021-05-021-17/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Propertly ignore ``Identity`` in MySQL and MariaDb.Federico Caselli2021-04-281-0/+3
| | | | | | | | | | | | | | Ensure that the MySQL and MariaDB dialect ignore the :class:`_sql.Identity` construct while rendering the ``AUTO_INCREMENT`` keyword in a create table. The Oracle and PostgreSQL compiler was updated to not render :class:`_sql.Identity` if the database version does not support it (Oracle < 12 and PostgreSQL < 10). Previously it was rendered regardless of the database version. Fixes: #6338 Change-Id: I2ca0902fdd7b4be4fc1a563cf5585504cbea9360
* Add new "sync once" mode for pool.connectMike Bayer2021-04-212-10/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ``scalar_one`` usage after ``unique``.Federico Caselli2021-04-171-54/+38
| | | | | | | | | | | | Fixed an issue that prevented using ``scalar_one`` or ``scalar_one_or_none()`` after a call to ``unique``. Additionally includes some clarifications in result.py and also removes pep-484 annotations for now as these are duplicate on top of sqlalchemy2-stubs. Fixes: #6299 Change-Id: Ia04f3d078c7a4f0d8488745e43d2fd63b60de9a0
* Merge "Support DEFAULT VALUES and VALUES(DEFAULT) individually"mike bayer2021-04-141-0/+10
|\
| * Support DEFAULT VALUES and VALUES(DEFAULT) individuallyMike Bayer2021-04-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-143-6/+34
|/ | | | | | | | | | | | | | 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
* Return Row for CursorResult.inserted_primary_keyMike Bayer2021-04-111-14/+20
| | | | | | | | | The tuple returned by :attr:`.CursorResult.inserted_primary_key` is now a :class:`_result.Row` object with a named tuple interface on top of the existing tuple interface. Fixes: #3314 Change-Id: I85677ef60d8329648f368bf497f634758f4e087b
View Lorry Controller Status