- fix mypy and linter issues
- expand BitString tests for int and bytes conversion
- Only run BIT test types on postgresql dialect
- Fix problems in `BitString.from_int` and `BitString.from_bytes`
- Add `BitString.to_bytes` method to allow specifying the byte
length of the returned instances
- Fixed problems testing operators in BIT type tests
- Added custom `BitString` implementation which inherits from `str`
and overrides methods and operators appropriately and
implements the bitwise operations in a manner consistent with
postgresql. Also exposes class and instance methods ensuring
instances can be converted to/from `int` and `bytes` sensibly.
- Added default implementations of `bind_processor` and
`result_processor` to `postgresql.BIT` type to convert `BitString`
to/from string for PG drivers.
- Override `bind_processor` and `result_processor` in AsyncpgBit
in order to convert `BitString` to/from `asynpg.BitString`
in `asyncpg` driver.
- Added support for bitwise comparators to postgresql `BIT` instances
Fixes: 10556
Fixed and added test support for a few SQLite SQL functions hardcoded into
the compiler most notably the "localtimestamp" function which rendered with
incorrect internal quoting.
Fixes: #12566
Change-Id: Id5bd8dc7841f0afab7df031ba5c0854dab845a1d
Identified some unnecessary cycles and overhead in how
this is implemented. since we want to add this to Select,
needs these improvements.
Change-Id: I4324db14aaf52ab87a8b7fa49ebf1b6624bc2dcb
Added support for the pow operator (``**``), with a default SQL
implementation of the ``POW()`` function. On Oracle Database, PostgreSQL
and MSSQL it renders as ``POWER()``. As part of this change, the operator
routes through a new first class ``func`` member :class:`_functions.pow`,
which renders on Oracle Database, PostgreSQL and MSSQL as ``POWER()``.
Fixes: #8579Closes: #8580
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8580
Pull-request-sha: 041b2ef474
Change-Id: I371bd44ed3e58f2d55ef705aeec7d04710c97f23
towards some refactorings I will need to do for #12496, this
factors out the "_ordered_values" list of tuples that was used to
track UPDATE VALUES in a specific order. The rationale for this
separate collection was due to Python dictionaries not maintaining
insert order. Now that this is standard behavior in Python 3
we can use the same `statement._values` for param-ordered and
table-column-ordered UPDATE rendering.
Change-Id: Id6024ab06e5e3ba427174e7ba3630ff83d81f603
Fixed regression caused by the DEFAULT rendering changes in 2.0.40
🎫`12425` where using lowercase `on update` in a MySQL server default
would incorrectly apply parenthesis, leading to errors when MySQL
interpreted the rendered DDL. Pull request courtesy Alexander Ruehe.
Fixes: #12488Closes: #12489
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12489
Pull-request-sha: b9008f747d
Change-Id: If5281c52415e4ddb6c2f8aee191d2335f6673b35
This is supported both for schema definition and reflection.
Fixes#10665.
Closes: #12485
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12485
Pull-request-sha: 1aabea7b55ece9fc0c6e069b777d4404ac01f964
Change-Id: I81d23966f84390dd1b03f0d13284ce6d883ee24e
Fixed issue where :meth:`.AsyncSession.get_transaction` and
:meth:`.AsyncSession.get_nested_transaction` would fail with
``NotImplementedError`` if the "proxy transaction" used by
:class:`.AsyncSession` were garbage collected and needed regeneration.
Fixes: #12471
Change-Id: Ia8055524618df706d7958786a500cdd25d9d8eaf
Implemented support for the GROUPS frame specification in window functions
by adding :paramref:`_sql.over.groups` option to :func:`_sql.over`
and :meth:`.FunctionElement.over`. Pull request courtesy Kaan Dikmen.
Fixes: #12450Closes: #12445
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12445
Pull-request-sha: c0808e135f
Change-Id: I9ff504a9c9650485830c4a0eaf44162898a3a2ad
Fixed regression caused by ``typing_extension==4.13.0`` that introduced
a different implementation for ``TypeAliasType`` while SQLAlchemy assumed
that it would be equivalent to the ``typing`` version.
Added test regarding generic TypeAliasType
Fixes: #12473Closes: #12472
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12472
Pull-request-sha: 8861a5acfb
Change-Id: I053019a222546a625ed6d588314ae9f5b34c2f8a
try again to remove the overloads to the generic functionn
generator (like coalesce, array_agg, etc).
As of mypy 1.15 it still does now work, but a simpler version
is added in this change
Change-Id: I8b97ae00298ec6f6bf8580090e5defff71e1ceb0
The return type of `array_agg()` is declared as a `Sequence[T]` where `T` is bound to the type of input argument.
This is implemented by making `array_agg()` inheriting from `ReturnTypeFromArgs` which provides appropriate overloads of `__init__()` to support this.
This usage of ReturnTypeFromArgs is a bit different from previous ones as the return type of the function is not exactly the same as that of its arguments, but a "collection" (a generic, namely a Sequence here) of the argument types. Accordingly, we adjust the code of `tools/generate_sql_functions.py` to retrieve the "collection" type from 'fn_class' annotation and generate expected return type.
Also add a couple of hand-written typing tests for PostgreSQL.
Related to #6810Closes: #12461
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12461
Pull-request-sha: ba27cbb863
Change-Id: I3fd538cc7092a0492c26970f0b825bf70ddb66cd
When building a PostgreSQL ``ARRAY`` literal using
:class:`_postgresql.array` with an empty ``clauses`` argument, the
:paramref:`_postgresql.array.type_` parameter is now significant in that it
will be used to render the resulting ``ARRAY[]`` SQL expression with a
cast, such as ``ARRAY[]::INTEGER``. Pull request courtesy Denis Laxalde.
Fixes: #12432Closes: #12435
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12435
Pull-request-sha: 9633d3c15d
Change-Id: I29ed7bd0562b82351d22de0658fb46c31cfe44f6
Fixed regression caused by 🎫`7471` leading to a SQL compilation
issue where name disambiguation for two same-named FROM clauses with table
aliasing in use at the same time would produce invalid SQL in the FROM
clause with two "AS" clauses for the aliased table, due to double aliasing.
Fixes: #12451
Change-Id: I981823f8f2cdf3992d65ace93a21fc20d1d74cda
A significant behavioral change has been made to the behavior of the
:paramref:`_orm.mapped_column.default` and
:paramref:`_orm.relationship.default` parameters, when used with
SQLAlchemy's :ref:`orm_declarative_native_dataclasses` feature introduced
in 2.0, where the given value (assumed to be an immutable scalar value) is
no longer passed to the ``@dataclass`` API as a real default, instead a
token that leaves the value un-set in the object's ``__dict__`` is used, in
conjunction with a descriptor-level default. This prevents an un-set
default value from overriding a default that was actually set elsewhere,
such as in relationship / foreign key assignment patterns as well as in
:meth:`_orm.Session.merge` scenarios. See the full writeup in the
:ref:`whatsnew_21_toplevel` document which includes guidance on how to
re-enable the 2.0 version of the behavior if needed.
This adds a new implicit default field to ScalarAttributeImpl
so that we can have defaults that are not in the dictionary but
are instead passed through to the class-level descriptor, effectively
allowing custom defaults that are not used in INSERT or merge
Fixes: #12168
Change-Id: Ia327d18d6ec47c430e926ab7658e7b9f0666206e
Fixed regression which occurred as of 2.0.37 where the checked
:class:`.ArgumentError` that's raised when an inappropriate type or object
is used inside of a :class:`.Mapped` annotation would raise ``TypeError``
with "boolean value of this clause is not defined" if the object resolved
into a SQL expression in a boolean context, for programs where future
annotations mode was not enabled. This case is now handled explicitly and
a new error message has also been tailored for this case. In addition, as
there are at least half a dozen distinct error scenarios for intepretation
of the :class:`.Mapped` construct, these scenarios have all been unified
under a new subclass of :class:`.ArgumentError` called
:class:`.MappedAnnotationError`, to provide some continuity between these
different scenarios, even though specific messaging remains distinct.
Fixes: #12329
Change-Id: I0193e3479c84a48b364df8655f050e2e84151122
Added syntax extension :func:`_postgresql.distinct_on` to build ``DISTINCT
ON`` clauses. The old api, that passed columns to
:meth:`_sql.Select.distinct`, is now deprecated.
Fixes: #12342
Change-Id: Ia6a7e647a11e57b6ac2f50848778c20dc55eaf54
Expanded the rules for when to apply parenthesis to a server default in DDL
to suit the general case of a default string that contains non-word
characters such as spaces or operators and is not a string literal.
Fixed issue in MySQL server default reflection where a default that has
spaces would not be correctly reflected. Additionally, expanded the rules
for when to apply parenthesis to a server default in DDL to suit the
general case of a default string that contains non-word characters such as
spaces or operators and is not a string literal.
Fixes: #12425
Change-Id: Ie40703dcd5fdc135025d676c01baba57ff3b71ad
Added support for specifying a list of columns for ``SET NULL`` and ``SET
DEFAULT`` actions of ``ON DELETE`` clause of foreign key definition on
PostgreSQL. Pull request courtesy Denis Laxalde.
Fixes: #11595Closes: #12421
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12421
Pull-request-sha: d0394db706
Change-Id: I036a559ae4a8efafe9ba64d776a840bd785a7397
The "non primary" mapper feature, long deprecated in SQLAlchemy since
version 1.3, has been removed. The sole use case for "non primary"
mappers was that of using :func:`_orm.relationship` to link to a mapped
class against an alternative selectable; this use case is now suited by the
:doc:`relationship_aliased_class` feature.
Fixes: #12437
Change-Id: I6987da06beb1d88d6f6e9696ce93e7fc340fc0ef
Improved static typing for `postgresql.array()` by making the type parameter (the type of array's elements) inferred from the `clauses` and `type_` arguments while also ensuring they are consistent.
Also completed type annotations of `postgresql.ARRAY` following commit 0bf7e02afb and added type annotations for functions `postgresql.Any()` and `postgresql.All()`.
Finally, fixed shadowing `typing.Any` by the `Any()` function through aliasing as `typing_Any`.
Related to #6810Closes: #12384
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12384
Pull-request-sha: 78eea29f1d
Change-Id: I5d35d15ec8ba4d58eeb9bf00abb710e2e585731f
Fixed issue in :class:`.CTE` constructs involving multiple DDL
:class:`.Insert` statements with multiple VALUES parameter sets where the
bound parameter names generated for these parameter sets would conflict,
generating a compile time error.
Fixes: #12363
Change-Id: If8344ff725d4e0ec58d3ff61f38a0edcfc5bdebd
not clear why this isn't happening on all py312s but this adjust
profiles for some memory changes that have occurred as of
88b77c8b19 - just the merge change, not the actual
code change for whatever reason. very strange
Change-Id: I67849259ea29e5bfb1527036e0d9f63071ec4d4d
Fixed issue in PostgreSQL network types :class:`_postgresql.INET`,
:class:`_postgresql.CIDR`, :class:`_postgresql.MACADDR`,
:class:`_postgresql.MACADDR8` where sending string values to compare to
these types would render an explicit CAST to VARCHAR, causing some SQL /
driver combinations to fail. Pull request courtesy Denis Laxalde.
Fixes: #12060Closes: #12412
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/12412
Pull-request-sha: 029fda7f2d
Change-Id: Id4a502ebc119775567cacddbabef2ce9715c1a9f
Thomas Stephenson