Gord Thompson [Mon, 8 Nov 2021 18:03:54 +0000 (11:03 -0700)]
De-emphasize notion of "default driver" (DBAPI)
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://`
Mike Bayer [Mon, 8 Nov 2021 15:36:11 +0000 (10:36 -0500)]
connection doc updates for future
* remove autocommit section, missed in future engine merge
* remove implicit execution section, also missed
* rewrite "transactions" section to fully discuss
"commit as you go" vs. "begin once", remove all references
to "future"
* fix up "understanding DBAPI autocommit" to be a little more
clear
Pushing this straight up, we can attend to remaining typos /
edits ad hoc
Mike Bayer [Mon, 1 Nov 2021 19:44:44 +0000 (15:44 -0400)]
fully implement future engine and remove legacy
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
Mike Bayer [Fri, 5 Nov 2021 14:18:42 +0000 (10:18 -0400)]
use tuple expansion if type._is_tuple, test for Sequence if no type
Fixed regression where the row objects returned for ORM queries, which are
now the normal :class:`_sql.Row` objects, would not be interpreted by the
:meth:`_sql.ColumnOperators.in_` operator as tuple values to be broken out
into individual bound parameters, and would instead pass them as single
values to the driver leading to failures. The change to the "expanding IN"
system now accommodates for the expression already being of type
:class:`.TupleType` and treats values accordingly if so. In the uncommon
case of using "tuple-in" with an untyped statement such as a textual
statement with no typing information, a tuple value is detected for values
that implement ``collections.abc.Sequence``, but that are not ``str`` or
``bytes``, as always when testing for ``Sequence``.
Added :class:`.TupleType` to the top level ``sqlalchemy`` import namespace.
Mike Bayer [Thu, 4 Nov 2021 21:02:24 +0000 (17:02 -0400)]
Check for Mapping explicitly in 2.0 params
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.
Mike Bayer [Thu, 4 Nov 2021 17:36:43 +0000 (13:36 -0400)]
Update "transaction has already begun" language
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.
Mike Bayer [Wed, 3 Nov 2021 15:32:51 +0000 (11:32 -0400)]
simplify and publicize the asyncpg JSON(B) codec registrsation
Added overridable methods ``PGDialect_asyncpg.setup_asyncpg_json_codec``
and ``PGDialect_asyncpg.setup_asyncpg_jsonb_codec`` codec, which handle the
required task of registering JSON/JSONB codecs for these datatypes when
using asyncpg. The change is that methods are broken out as individual,
overridable methods to support third party dialects that need to alter or
disable how these particular codecs are set up.
Mike Bayer [Thu, 4 Nov 2021 01:26:44 +0000 (21:26 -0400)]
use ExpressionElementRole for case targets in case()
Fixed regression where the :func:`_sql.text` construct would no longer be
accepted as a target case in the "whens" list within a :func:`_sql.case`
construct. The regression appears related to an attempt to guard against
some forms of literal values that were considered to be ambiguous when
passed here; however, there's no reason the target cases shouldn't be
interpreted as open-ended SQL expressions just like anywhere else, and a
literal string or tuple will be converted to a bound parameter as would be
the case elsewhere.
Fixed issue in visit_on_duplicate_key_update within a composed expression
Fixed issue in MySQL :meth:`_mysql.Insert.on_duplicate_key_update` which
would render the wrong column name when an expression were used in a VALUES
expression. Pull request courtesy Cristian Sabaila.
Gord Thompson [Tue, 2 Nov 2021 22:16:50 +0000 (16:16 -0600)]
Gracefully degrade unsupported types with asyncpg
Fixes: #7284
Modify the on_connect() method of PGDialect_asyncpg to
gracefully degrade unsupported types instead of throwing a
ValueError. Useful for third-party dialects that derive
from PGDialect_asyncpg but whose databases do not support
all types (e.g., CockroachDB supports JSONB but not JSON).
Mike Bayer [Tue, 2 Nov 2021 14:58:01 +0000 (10:58 -0400)]
ensure soft_close occurs for fetchmany with server side cursor
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.
Mike Bayer [Mon, 1 Nov 2021 20:36:51 +0000 (16:36 -0400)]
use full context manager flow for future.Engine.begin()
Fixed issue in future :class:`_future.Engine` where calling upon
:meth:`_future.Engine.begin` and entering the context manager would not
close the connection if the actual BEGIN operation failed for some reason,
such as an event handler raising an exception; this use case failed to be
tested for the future version of the engine. Note that the "future" context
managers which handle ``begin()`` blocks in Core and ORM don't actually run
the "BEGIN" operation until the context managers are actually entered. This
is different from the legacy version which runs the "BEGIN" operation up
front.
Mike Bayer [Sun, 31 Oct 2021 16:54:23 +0000 (12:54 -0400)]
remove case_sensitive create_engine parameter
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.
Mike Bayer [Mon, 1 Nov 2021 16:06:32 +0000 (12:06 -0400)]
Revise "literal parameters" FAQ section
based on feedback in #7271, the emphasis on TypeDecorator
as a solution to this problem is not very practical. illustrate
a series of quick recipes that are useful for debugging purposes
to print out a repr() or simple stringify of a parameter
without the need to construct custom dialects or types.
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.
Federico Caselli [Sun, 10 Oct 2021 08:41:13 +0000 (10:41 +0200)]
The ``has_table`` method now also checks views
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.
Mike Bayer [Sun, 31 Oct 2021 00:45:26 +0000 (20:45 -0400)]
remove ORM autocommit and public-facing subtransactions concept
In order to do LegacyRow we have to do Connection, which means
we lose close_with_result (hooray) which then means we
have to get rid of ORM session autocommit which relies on it, so
let's do that first.
Mike Bayer [Fri, 29 Oct 2021 21:36:26 +0000 (17:36 -0400)]
warnings removal, merge_result
this is the last warning to remove.
Also fixes some mistakes I made with the new
Base20DeprecationWarning and LegacyAPIWarning classes created,
where functions in deprecations.py were still hardcoded to
RemovedIn20Warning.
most of the work for aliased / from_joinpoint has been done
already as I added all new tests for these and moved
most aliased/from_joinpoint to test/orm/test_deprecations.py
already
Mike Bayer [Wed, 27 Oct 2021 15:14:50 +0000 (11:14 -0400)]
consider "inspect(_of_type)" to be the entity of a comparator
Fixed 1.4 regression where :meth:`_orm.Query.filter_by` would not function
correctly when :meth:`_orm.Query.join` were joined to an entity which made
use of :meth:`_orm.PropComparator.of_type` to specify an aliased version of
the target entity. The issue also applies to future style ORM queries
constructed with :func:`_sql.select`.
Mike Bayer [Tue, 26 Oct 2021 19:52:25 +0000 (15:52 -0400)]
add additional "oracle mode" reserved words
despite mariadb's docs, the word "system" must be
quoted in plain mariadb 10.5, not sure if that's
"oracle mode" but it is > 10.3. observed keystone
tests failing on a column of this name.
Mike Bayer [Tue, 26 Oct 2021 15:28:42 +0000 (11:28 -0400)]
dont pull filter_by from from_obj, entity is hopefully sufficient
Fixed 1.4 regression where :meth:`_orm.Query.filter_by` would not function
correctly on a :class:`_orm.Query` that was produced from
:meth:`_orm.Query.union`, :meth:`_orm.Query.from_self` or similar.
jonathan vanasco [Fri, 24 Sep 2021 18:55:59 +0000 (14:55 -0400)]
Fixes: #4100
Add a warning, in two places, stating `with_for_update` will lock joinedload
tables, because at least one person did not expect the obvious to happen.
Also warn that eager loading techniques may not work with `with_for_update`
and combining the two is not officially supported or recommended.
Mike Bayer [Wed, 20 Oct 2021 16:50:53 +0000 (12:50 -0400)]
deprecation warnings: strings in loader options, join, with_parent
Repairs one in-library deprecation warning regarding
mapper propagation of options
raises maxfail to 250, as 25 is too low when we are trying
to address many errors at once. the 25 was originally
due to the fact that our fixtures would be broken after
that many failures in most cases, which today should not
be the case nearly as often.
Mike Bayer [Sun, 24 Oct 2021 00:36:41 +0000 (20:36 -0400)]
add full docs/notes for all TypeEngine/TypeDecorator interactions
Added notes to all TypeEngine methods as to which should be
overridden by TypeDecorator implementations. Made sure
docstrings are present for all TypeDecorator methods as some
were missing, and clarified which should be overridden, which
should not, as well as what phase each method is called within.
Mike Bayer [Fri, 22 Oct 2021 16:31:06 +0000 (12:31 -0400)]
use correct entity in path for aliased class relationship
Fixed bug in "relationship to aliased class" feature introduced at
:ref:`relationship_aliased_class` where it was not possible to create a
loader strategy option targeting an attribute on the target using the
:func:`_orm.aliased` construct directly in a second loader option, such as
``selectinload(A.aliased_bs).joinedload(aliased_b.cs)``, without explicitly
qualifying using :meth:`_orm.PropComparator.of_type` on the preceding
element of the path. Additionally, targeting the non-aliased class directly
would be accepted (inappropriately), but would silently fail, such as
``selectinload(A.aliased_bs).joinedload(B.cs)``; this now raises an error
referring to the typing mismatch.
Gord Thompson [Wed, 20 Oct 2021 21:15:37 +0000 (15:15 -0600)]
Apply minor update to async_orm example
- Fixed import to avoid MovedIn20Warning.
- Separated drop_all() and create_all() into separate
context managers to avoid dropping and creating the
same table within the same transaction. Apparently
some databases (e.g., CockroachDB) don't allow that.
Kevin Kirsche [Tue, 19 Oct 2021 21:22:03 +0000 (17:22 -0400)]
fix: Update reserved words list of MySQL / MariaDB dialect
Reorganized the list of reserved words into two separate lists, one for
MySQL and one for MariaDB, so that these diverging sets of words can be
managed more accurately; adjusted the MySQL/MariaDB dialect to switch among
these lists based on either explicitly configured or
server-version-detected "MySQL" or "MariaDB" backend. Added all current
reserved words through MySQL 8 and current MariaDB versions including
recently added keywords like "lead" . Pull request courtesy Kevin Kirsche.
1. Move reserved words to it's own file.
2. Add missing reserved words from https://mariadb.com/kb/en/reserved-words/
* Note: this only adds MariaDB though links to MySQL, it also does not
include the reserved words for Oracle mode, as listed in the link.
Mike Bayer [Mon, 18 Oct 2021 20:35:21 +0000 (16:35 -0400)]
remove _resolve_label and related attributes
these seem to date back to 0.9 and revs like #3148 but none
of it seems to be affecting things now, try removing it all
and seeing what fails.
we've noted that _resolve_label does not appear to be
needed, however allow_label_resolve remains relevant both
for non-column elements like text() as well as that it is
used explicitly by the joined eager loader.
Mike Bayer [Tue, 19 Oct 2021 18:07:32 +0000 (14:07 -0400)]
process bulk_update_tuples before cache key or compilation
Fixed regression where the use of a :class:`_orm.hybrid_property` attribute
or a mapped :func:`_orm.composite` attribute as a key passed to the
:meth:`_dml.Update.values` method for an ORM-enabled :class:`_dml.Update`
statement, as well as when using it via the legacy
:meth:`_orm.Query.update` method, would be processed for incoming
ORM/hybrid/composite values within the compilation stage of the UPDATE
statement, which meant that in those cases where caching occurred,
subsequent invocations of the same statement would no longer receive the
correct values. This would include not only hybrids that use the
:meth:`_orm.hybrid_property.update_expression` method, but any use of a
plain hybrid attribute as well. For composites, the issue instead caused a
non-repeatable cache key to be generated, which would break caching and
could fill up the statement cache with repeated statements.
The :class:`_dml.Update` construct now handles the processing of key/value
pairs passed to :meth:`_dml.Update.values` and
:meth:`_dml.Update.ordered_values` up front when the construct is first
generated, before the cache key has been generated so that the key/value
pairs are processed each time, and so that the cache key is generated
against the individual column/value pairs that will ultimately be
used in the statement.
Mike Bayer [Mon, 18 Oct 2021 19:43:27 +0000 (15:43 -0400)]
use coercions for label element, ensure propagate_attrs
Fixed bug where the ORM "plugin", necessary for features such as
:func:`_orm.with_loader_criteria` to work correctly, would not be applied
to a :func:`_sql.select` which queried from an ORM column expression if it
made use of the :meth:`_sql.ColumnElement.label` modifier.
Mike Bayer [Fri, 15 Oct 2021 15:03:46 +0000 (11:03 -0400)]
fix with_loader_criteria for select(A).join(B)
Also revise the contains_eager() note that was just
added in fec2b6560c14bb28ee7f, as I mistakenly forgot that
WLC also affects elements of the query that are there
as part of the normal entites/criteria.
projects / thirdparty / sqlalchemy / sqlalchemy.git / log
