| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | |
| | | |
this is needed due to previous commit f7bfa04bcae1e9baf
Change-Id: I7fa397707a018455a2c96b62704dfd506742b0cd
|
|/ /
| |
| |
| |
| |
| |
| | |
I thought this was documented but apparently not.
Fixes: #9658
Change-Id: I93fad12c159c599ffdbab1aff586b49e8c92a6e4
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
References: #9606
Change-Id: I1213f881621a80eb78a2db84e53150437144f26c
|
|\ \ \
| |/ /
|/| | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added :func:`_sa.create_pool_from_url` and
:func:`_asyncio.create_async_pool_from_url` to create
a :class:`_pool.Pool` instance from an input url passed as string
or :class:`_sa.URL`.
Fixes: #9613
Change-Id: Icd8aa3f2849e6fd1bc5341114f3ef8d216a2c543
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| | |
Removed versionadded and versionchanged for version prior to 1.2 since they
are no longer useful.
Change-Id: I5c53d1188bc5fec3ab4be39ef761650ed8fa6d3e
|
|\ \
| |/
|/|
| | |
perspective" into main
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed bug in ORM Declarative Dataclasses where the
:func:`_orm.queryable_attribute` and :func:`_orm.column_property`
constructs, which are documented as read-only constructs in the context of
a Declarative mapping, could not be used with a
:class:`_orm.MappedAsDataclass` class without adding ``init=False``, which
in the case of :func:`_orm.queryable_attribute` was not possible as no
``init`` parameter was included. These constructs have been modified from a
dataclass perspective to be assumed to be "read only", setting
``init=False`` by default and no longer including them in the pep-681
constructor. The dataclass parameters for :func:`_orm.column_property`
``init``, ``default``, ``default_factory``, ``kw_only`` are now deprecated;
these fields don't apply to :func:`_orm.column_property` as used in a
Declarative dataclasses configuration where the construct would be
read-only. Also added read-specific parameter
:paramref:`_orm.queryable_attribute.compare` to
:func:`_orm.queryable_attribute`; :paramref:`_orm.queryable_attribute.repr`
was already present.
Added missing :paramref:`_orm.mapped_column.active_history` parameter
to :func:`_orm.mapped_column` construct.
Fixes: #9628
Change-Id: I2ab44d6b763b20410bd1ebb5ac949a6d223f1ce2
|
| |
| |
| |
| | |
Change-Id: I7104c7cb081c9b61894958cef5d0b4707474994d
|
|/
|
|
|
|
|
|
| |
Minor corrections to "Simplifying Association
Objects" example in the Association Proxy docs.
https: //github.com/sqlalchemy/sqlalchemy/discussions/9636
Change-Id: Ib433cf78b149d330889d947bbaf2b03c9dd87c29
|
|
|
|
| |
Change-Id: Ice0233af37f387747a283ef2d2293aaa194b52d9
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed issue where the :meth:`_orm.declared_attr.directive` modifier was not
correctly honored for subclasses when applied to the ``__mapper_args__``
special method name, as opposed to direct use of
:class:`_orm.declared_attr`. The two constructs should have identical
runtime behaviors.
Fixes: #9625
Change-Id: I0dfe9e73bb45f70dbebc8e94ce280ad3b52e867f
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| | |
Currently using the PR for test.
Change-Id: Idc4c475587f5151ef79046d24ca3ac274c2cb2ca
References: https://github.com/python/mypy/issues/14868
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
since I am probably using this for the new "sentinel" thing,
clean up this code, reduce codepaths and inline a bit
Change-Id: I9cb312828e3bc23636f6db794b169f1acc4ebae3
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixed issue that prevented reflection of expression based indexes
with long expressions in PostgreSQL. The expression where erroneously
truncated to the identifier length (that's 63 bytes by default).
Fixes: #9615
Change-Id: I50727b0699e08fa25f10f3c94dcf8b79534bfb75
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Restored the :paramref:`_postgresql.ENUM.name` parameter as optional in the
signature for :class:`_postgresql.ENUM`, as this is chosen automatically
from a given pep-435 ``Enum`` type.
Fixed issue where the comparison for :class:`_postgresql.ENUM` against a
plain string would cast that right-hand side type as VARCHAR, which due to
more explicit casting added to dialects such as asyncpg would produce a
PostgreSQL type mismatch error.
Fixes: #9611
Fixes: #9621
Change-Id: If095544cd1a52016ad2e7cfa2d70c919a94e79c1
|
| | |
| | |
| | |
| | | |
Change-Id: I6a46046af5b6ed484b470057761e77b485e2e061
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | | |
Change-Id: If6f2efd7cd443593a8e7ca06109e51cfd07ed020
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In #9618 we both can look to re-enable insertmanyvalues
for SQL Server, and also likely *disable* its use for the
ORM unit of work specifically, since that's really where the
only problem is, and it will likely be for all dialects,
not just SQL Server. An approach using sentinel columns will
be rolled out for the unit of work use case.
Change-Id: I3358e30839491769db95b4ac042a661271df3929
References: #9618
References: #9603
|
| | |
| | |
| | |
| | |
| | | |
I found an extremely and probably insignificant typo in the doc for `mapped_column` while actually trying to use and understand it for my project and have fixed it here.
The typo was for a "for" which was instead mentioned as "or".
|
|/ /
| |
| | |
Fix literal text in example
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
this would be misleading due to #9603 disabling insertmanyvalues
across the board.
Change-Id: I0e746e13f8ad054207790644cb43eba101dde30c
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we will keep trying to find workarounds, however this
patch is the "turn it off" patch
Due to a critical bug identified in SQL Server, the SQLAlchemy
"insertmanyvalues" feature which allows fast INSERT of many rows while also
supporting RETURNING unfortunately needs to be disabled for SQL Server. SQL
Server is apparently unable to guarantee that the order of rows inserted
matches the order in which they are sent back by OUTPUT inserted when
table-valued rows are used with INSERT in conjunction with OUTPUT inserted.
We are trying to see if Microsoft is able to confirm this undocumented
behavior however there is no known workaround, other than it's not safe to
use table-valued expressions with OUTPUT inserted for now.
Fixes: #9603
Change-Id: I4b932fb8774390bbdf4e870a1f6cfe9a78c4b105
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed endless loop which could occur when using "relationship to aliased
class" feature and also indicating a recursive eager loader such as
``lazy="selectinload"`` in the loader, in combination with another eager
loader on the opposite side. The check for cycles has been fixed to include
aliased class relationships.
Fixes: #9590
Change-Id: I8d340882f040ff9289c209bedd8fbdfd7186f944
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Fixes: #9588
References: #9585
Change-Id: Ic6668311ea488339023d7aab1a186f8465131fd8
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changed the bulk INSERT strategy used for SQL Server "executemany" with
pyodbc when ``fast_executemany`` is set to ``True`` by using
``fast_executemany`` / ``cursor.executemany()`` for bulk INSERT that does
not include RETURNING, restoring the same behavior as was used in
SQLAlchemy 1.4 when this parameter is set. For INSERT statements that use
RETURNING, the "insertmanyvalues" strategy continues to be used as it is
the only current strategy that supports RETURNING with bulk INSERT.
Previously, SQLAlchemy 2.0 would use "insertmanyvalues" for all INSERT
statements when ``use_insertmanyvalues`` was left at its default of
``False``, ignoring if ``fast_executemany`` was set.
New performance details from end users have shown that ``fast_executemany``
is still much faster for very large datasets as it uses ODBC commands that
can receive all rows in a single round trip, allowing for much larger
datasizes than the batches that can be sent by the current
"insertmanyvalues" strategy.
Fixes: #9586
Change-Id: I85955a10ba77c26cdc0c22e362a827d7aaef2852
|
| |
|
| |
|
|
|
|
| |
Change-Id: I611684872ea34d05cc5d81ade0813676df00e03f
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exceptions such as ``TypeError`` and ``ValueError`` raised by Python
dataclasses when making use of the :class:`_orm.MappedAsDataclass` mixin
class or :meth:`_orm.registry.mapped_as_dataclass` decorator are now
wrapped within an :class:`.InvalidRequestError` wrapper along with
informative context about the error message, referring to the Python
dataclasses documentation as the authoritative source of background
information on the cause of the exception.
Fixes: #9563
Change-Id: I25652485b91c4ee8cf112b91aae8f9041061a8bd
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed issue where an annotation-only :class:`_orm.Mapped` directive could
not be used in a Declarative mixin class, without that attribute attempting
to take effect for single- or joined-inheritance subclasses of mapped
classes that had already mapped that attribute on a superclass, producing
conflicting column errors and/or warnings.
Fixes: #9564
Change-Id: I0f92be2ae98a8c45afce3e06d0a7cc61c19a96f4
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed issue where the :func:`_orm.mapped_column` construct would raise an
internal error if used on a Declarative mixin and included the
:paramref:`_orm.mapped_column.deferred` parameter.
Fixes: #9550
Change-Id: I0cc5ec4910656abc9a3fb7b7b60880256cd7c61e
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implemented missing method ``copy`` and ``pop`` in OrderedSet class.
Fixes: #9487
Change-Id: I1d2278b64939b44422e9d5857ec7d345fff53997
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
main
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fields that are declared on Declarative Mixins and then combined with
classes that make use of :class:`_orm.MappedAsDataclass`, where those mixin
fields are not themselves part of a dataclass, now emit a deprecation
warning as these fields will be ignored in a future release, as Python
dataclasses behavior is to ignore these fields. Type checkers will not see
these fields under pep-681.
Fixes: #9350
Change-Id: Ie0a0ac0f0bb58d1c2aae13b4a8dcd0439a4f5477
|