]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
Establish Oracle outputtypehandlers for JSON expressions
authorMike Bayer <mike_mp@zzzcomputing.com>
Tue, 4 Aug 2026 19:51:02 +0000 (15:51 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Wed, 5 Aug 2026 14:56:14 +0000 (10:56 -0400)
commit2e881c11262e6a2e808644cc6838c80f1dfadcdd
tree0b0652f10d7a8891919ebdcf783fb9e66c4a5f56
parent69261e85fb3b0c32fa69bca9fa27bceda6b2fbe4
Establish Oracle outputtypehandlers for JSON expressions

Fixed issue in the Oracle dialects where a :class:`_types.JSON` value would
be returned as an undecoded string for any JSON expression that is not a
JSON column, such as a bound parameter, as well as for textual constructs
with positional columns, such as :func:`_expression.text` combined with
:meth:`_expression.TextClause.columns`.

Native JSON columns previously worked only because the driver decodes
DB_TYPE_JSON on its own; the only JSON-aware handler was the
connection-level one, which fires solely for DB_TYPE_JSON and only when a
custom json_deserializer is configured.  _OracleJson now supplies a
_cx_oracle_outputtypehandler() of its own, covering JSON expressions that
arrive as VARCHAR / NVARCHAR / CLOB.

Additionally, the per-statement cursor outputtypehandler matched the
compiled result columns against the driver's result columns by name.  For a
TextualSelect the names reported by cursor.description are generated by the
database and have no relationship to the names given to .columns(), so no
handler was installed at all.  Handlers are now matched positionally when
_textual_ordered_columns is set, consistent with how CursorResultMetaData
already merges these constructs.

Fixes: #13479
Change-Id: I55e38d8e493ff016f9196c4567b195f3c15e338a
doc/build/changelog/unreleased_21/13479.rst [new file with mode: 0644]
lib/sqlalchemy/dialects/oracle/cx_oracle.py
test/dialect/oracle/test_types.py