:tickets: 6515
Fixed bug in :class:`.ARRAY` datatype in combination with :class:`.Enum` on
- PostgreSQL where using the ``.any()`` method to render SQL ANY(), given
- members of the Python enumeration as arguments, would produce a type
- adaptation failure on all drivers.
+ PostgreSQL where using the ``.any()`` or ``.all()`` methods to render SQL
+ ANY() or ALL(), given members of the Python enumeration as arguments, would
+ produce a type adaptation failure on all drivers.
--- /dev/null
+.. change::
+ :tags: bug, engine
+ :tickets: 7875
+
+ Fixed a memory leak in the C extensions which could occur when calling upon
+ named members of :class:`.Row` when the member does not exist under Python
+ 3; in particular this could occur during NumPy transformations when it
+ attempts to call members such as ``.__array__``, but the issue was
+ surrounding any ``AttributeError`` thrown by the :class:`.Row` object. This
+ issue does not apply to version 2.0 which has already transitioned to
+ Cython. Thanks much to Sebastian Berg for identifying the problem.
+
:tags: bug, postgresql
:tickets: 7930
- Fixed an issue what would cause autocommit mode to be reset
- when using pre_ping in conjunction engine level autocommit
- on the psycopg2 driver.
+ Fixed an issue in the psycopg2 dialect when using the
+ :paramref:`.create_engine.pool_pre_ping` parameter which would cause
+ user-configured ``AUTOCOMMIT`` isolation level to be inadvertently reset by
+ the "ping" handler.
:tags: bug, orm, regression
:tickets: 7936
- Fixed regression where the change in #7861, released in version 1.4.33,
- that brought the :class:`.Insert` construct to be partially recognized as
- an ORM-enabled statement did not properly transfer the correct mapper /
- mapped table state to the :class:`.Session`, causing the
+ Fixed regression where the change made for :ticket:`7861`, released in
+ version 1.4.33, that brought the :class:`.Insert` construct to be partially
+ recognized as an ORM-enabled statement did not properly transfer the
+ correct mapper / mapped table state to the :class:`.Session`, causing the
:meth:`.Session.get_bind` method to fail for a :class:`.Session` that was
bound to engines and/or connections using the :paramref:`.Session.binds`
parameter.
:tags: bug, asyncio
:tickets: 7937
- Allow setting contextvar values inside async adapted event handlers.
- Previously the value set to the contextvar would not be properly
- propagated.
+ Repaired handling of ``contextvar.ContextVar`` objects inside of async
+ adapted event handlers. Previously, values applied to a ``ContextVar``
+ would not be propagated in the specific case of calling upon awaitables
+ inside of non-awaitable code.
:tickets: 7943
Implemented :attr:`_postgresql.UUID.python_type` attribute for the
- :class:`_postgresql.UUID` type object. The attribute will return either
- ``str`` or ``uuid.UUID`` based on the :paramref:`_postgresql.UUID.as_uuid`
- parameter setting. Previously, this attribute was unimplemented. Pull
- request courtesy Alex Grönholm.
\ No newline at end of file
+ PostgreSQL :class:`_postgresql.UUID` type object. The attribute will return
+ either ``str`` or ``uuid.UUID`` based on the
+ :paramref:`_postgresql.UUID.as_uuid` parameter setting. Previously, this
+ attribute was unimplemented. Pull request courtesy Alex Grönholm.
\ No newline at end of file
:tags: bug, engine
:tickets: 7953
- Fixed issue in :meth:`.Result.columns` method where calling upon
- :meth:`.Result.columns` with a single index could in some cases,
- particularly ORM result object cases, cause the :class:`.Result` to yield
- scalar objects rather than :class:`.Row` objects, as though the
- :meth:`.Result.scalars` method had been called. In SQLAlchemy 1.4, this
- scenario emits a warning that the behavior will change in SQLAlchemy 2.0.
+ Added a warning regarding a bug which exists in the :meth:`.Result.columns`
+ method when passing 0 for the index in conjunction with a :class:`.Result`
+ that will return a single ORM entity, which indicates that the current
+ behavior of :meth:`.Result.columns` is broken in this case as the
+ :class:`.Result` object will yield scalar values and not :class:`.Row`
+ objects. The issue will be fixed in 2.0, which would be a
+ backwards-incompatible change for code that relies on the current broken
+ behavior. Code which wants to receive a collection of scalar values should
+ use the :meth:`.Result.scalars` method, which will return a new
+ :class:`.ScalarResult` object that yields non-row scalar objects.
+
the table alone without using a column name, if the name of the referent
column is the same as that of the referred column.
- The ``referred_column_0`` naming convention key was not previously not
- tested with the :class:`.ForeignKey` object, only
- :class:`.ForeignKeyConstraint`, and this bug reveals that the feature has
- never worked correctly unless :class:`.ForeignKeyConstraint` is used for
- all FK constraints. This bug traces back to the original introduction of
- the feature introduced for :ticket:`3989`.
+ The ``referred_column_0`` naming convention key was previously not tested
+ with the :class:`.ForeignKey` object, only :class:`.ForeignKeyConstraint`,
+ and this bug reveals that the feature has never worked correctly unless
+ :class:`.ForeignKeyConstraint` is used for all FK constraints. This bug
+ traces back to the original introduction of the feature introduced for
+ :ticket:`3989`.
--- /dev/null
+.. change::
+ :tags: bug, engine
+ :tickets: 7953
+
+ Fixed issue in :meth:`.Result.columns` method where calling upon
+ :meth:`.Result.columns` with a single index could in some cases,
+ particularly ORM result object cases, cause the :class:`.Result` to yield
+ scalar objects rather than :class:`.Row` objects, as though the
+ :meth:`.Result.scalars` method had been called. In SQLAlchemy 1.4, this
+ scenario emits a warning that the behavior will change in SQLAlchemy 2.0.
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
