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
Change-Id: I1ef2eb2018f4b68825fe40a2a8d99084cf217b35 References: #7257
Fixes: #6960 Even though a default driver still exists for each dialect, remove most usages of `dialect://` to encourage users to explicitly specify `dialect+driver://` Change-Id: I0ad42167582df509138fca64996bbb53e379b1af
The major action here is to lift and move future.Connection and future.Engine fully into sqlalchemy.engine.base. This removes lots of engine concepts, including: * autocommit * Connection running without a transaction, autobegin is now present in all cases * most "autorollback" is obsolete * Core-level subtransactions (i.e. MarkerTransaction) * "branched" connections, copies of connections * execution_options() returns self, not a new connection * old argument formats, distill_params(), simplifies calling scheme between engine methods * before/after_execute() events (oriented towards compiled constructs) don't emit for exec_driver_sql(). before/after_cursor_execute() is still included for this * old helper methods superseded by context managers, connection.transaction(), engine.transaction() engine.run_callable() * ancient engine-level reflection methods has_table(), table_names() * sqlalchemy.testing.engines.proxying_engine References: #7257 Change-Id: Ib20ed816642d873b84221378a9ec34480e01e82c
Fixed bug where iterating a :class:`.Result` from a :class:`_orm.Session` after that :class:`_orm.Session` were closed would partially attach objects to that session in an essentially invalid state. It now raises an exception with a link to new documentation if an **un-buffered** result is iterated from a :class:`_orm.Session` that was closed or otherwise had the :meth:`_orm.Session.expunge_all` method called after that :class:`.Result` was generated. The "prebuffer_rows" execution option, as is used by the asyncio extension, may be used to produce a :class:`.Result` where the ORM objects are prebuffered, and in this case iterating the result will produce a series of detached objects. Fixes: #7128 Change-Id: I59f0ae32a83a64587937741b80f31ff825bbb574
An extra layer of warning messages has been added to the functionality of :meth:`_orm.Query.join` and the ORM version of :meth:`_sql.Select.join`, where a few places where "automatic aliasing" continues to occur will now be called out as a pattern to avoid, mostly specific to the area of joined table inheritance where classes that share common base tables are being joined together without using explicit aliases. One case emits a legacy warning for a pattern that's not recommended, the other case is fully deprecated. The automatic aliasing within ORM join() which occurs for overlapping mapped tables does not work consistently with all APIs such as ``contains_eager()``, and rather than continue to try to make these use cases work everywhere, replacing with a more user-explicit pattern is clearer, less prone to bugs and simplifies SQLAlchemy's internals further. The warnings include links to the errors.rst page where each pattern is demonstrated along with the recommended pattern to fix. * Improved the exception message generated when configuring a mapping with joined table inheritance where the two tables either have no foreign key relationships set up, or where they have multiple foreign key relationships set up. The message is now ORM specific and includes context that the :paramref:`_orm.Mapper.inherit_condition` parameter may be needed particularly for the ambiguous foreign keys case. * Add explicit support in the _expect_warnings() assertion for nested _expect_warnings calls * generalize the NoCache fixture, which we also need to catch warnings during compilation consistently * generalize the __str__() method for the HasCode mixin so all warnings and errors include the code link in their string Fixes: #6974 Change-Id: I84ed79ba2112c39eaab7973b6d6f46de7fa80842
Provide better error message when trying to insepct and async engine or asnyc connection. Change-Id: I907f3a22c6b76fe43df9d40cb0e69c57f74a7982
(redo of 2999/I5609025feee8cfdecc09b55bfbf1bd13fa2e6602) This PR is designed to bring more clarity within the docs by renaming object instances that may be consfusingly similar to class, method, and attribute names. For example, instances of the class `MetaData` are available on some objects as `.metadata` property, and had appeared within the docs as both `meta` and `metadata` which has confused some users in the past. By this PR, the docs now utilize the following naming convention: * MetaData - SQLAlchemy class * .metadata - SQLAlchemy API attributes * metadata_obj - developer instantiated metadata objects or references Detailed Changes: * standardized `meta` and `metadata` instances to `metadata_obj`. note: the docs were evenly split between 'meta' and 'metadata'. * standardized 'cursor' to 'cursor_obj' to avoid confusion with the method. * standardized a 'scalar_subquery = ' to 'scalar_subq' to avoid confusion with the method. * standardized a 'cte = ' to 'cte_obj' to avoid confusion with the method Change-Id: I79c98aee16c5fc6649289b2dd7d6dfc368222fb4
The warning that's emitted for :func:`_orm.relationship` when multiple relationships would overlap with each other as far as foreign key attributes written towards, now includes the specific "overlaps" argument to use for each warning in order to silence the warning without changing the mapping. Fixes: #6400 Change-Id: I43c04f8018dda4e0f83ae58b8c7fd95084d9e95d