diff options
| author | Mike Bayer <mike_mp@zzzcomputing.com> | 2020-08-15 15:08:09 -0400 |
|---|---|---|
| committer | Mike Bayer <mike_mp@zzzcomputing.com> | 2020-08-17 11:29:51 -0400 |
| commit | 3b4bbbb2a3d337d0af1ba5ccb0d29d1c48735e83 (patch) | |
| tree | b3d3e90e7d0f22451e8d4e9e29ef82664e6dd4d4 /doc | |
| parent | 8a274e0058183cebeb37d3a5e7903209ce5e7c0e (diff) | |
| download | sqlalchemy-3b4bbbb2a3d337d0af1ba5ccb0d29d1c48735e83.tar.gz | |
Create a real type for Tuple() and handle appropriately in compiler
Improved the :func:`_sql.tuple_` construct such that it behaves predictably
when used in a columns-clause context. The SQL tuple is not supported as a
"SELECT" columns clause element on most backends; on those that do
(PostgreSQL, not surprisingly), the Python DBAPI does not have a "nested
type" concept so there are still challenges in fetching rows for such an
object. Use of :func:`_sql.tuple_` in a :func:`_sql.select` or
:class:`_orm.Query` will now raise a :class:`_exc.CompileError` at the
point at which the :func:`_sql.tuple_` object is seen as presenting itself
for fetching rows (i.e., if the tuple is in the columns clause of a
subquery, no error is raised). For ORM use,the :class:`_orm.Bundle` object
is an explicit directive that a series of columns should be returned as a
sub-tuple per row and is suggested by the error message. Additionally ,the
tuple will now render with parenthesis in all contexts. Previously, the
parenthesization would not render in a columns context leading to
non-defined behavior.
As part of this change, Tuple receives a dedicated datatype
which appears to allow us the very desirable change of removing
the bindparam._expanding_in_types attribute as well as
ClauseList._tuple_values (which might already have not been
needed due to #4645).
Fixes: #5127
Change-Id: Iecafa0e0aac2f1f37ec8d0e1631d562611c90200
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/build/changelog/unreleased_14/5127.rst | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/build/changelog/unreleased_14/5127.rst b/doc/build/changelog/unreleased_14/5127.rst new file mode 100644 index 000000000..94e584649 --- /dev/null +++ b/doc/build/changelog/unreleased_14/5127.rst @@ -0,0 +1,19 @@ +.. change:: + :tags: bug, sql + :tickets: 5127 + + Improved the :func:`_sql.tuple_` construct such that it behaves predictably + when used in a columns-clause context. The SQL tuple is not supported as a + "SELECT" columns clause element on most backends; on those that do + (PostgreSQL, not surprisingly), the Python DBAPI does not have a "nested + type" concept so there are still challenges in fetching rows for such an + object. Use of :func:`_sql.tuple_` in a :func:`_sql.select` or + :class:`_orm.Query` will now raise a :class:`_exc.CompileError` at the + point at which the :func:`_sql.tuple_` object is seen as presenting itself + for fetching rows (i.e., if the tuple is in the columns clause of a + subquery, no error is raised). For ORM use,the :class:`_orm.Bundle` object + is an explicit directive that a series of columns should be returned as a + sub-tuple per row and is suggested by the error message. Additionally ,the + tuple will now render with parenthesis in all contexts. Previously, the + parenthesization would not render in a columns context leading to + non-defined behavior. |