Thin mode: an outputtypehandler redefining a CLOB as DB_TYPE_LONG misreads the reply when the statement is cached

Abierto
  • ¿Algo no está bien?
#634 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

  • #635 de @lemenkov — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
python
Área
backend-api-design, database

Línea de trabajo

Start with MessageWithData._preprocess_query() in src/oracledb/impl/thin/messages/base.pyx and compare its output type handler change handling with _process_error_info() for ORA-00932. The report says a linked pull request contains a fix, so review that change and the related cursor and LOB tests: tests/cursor, tests/data_types/test_1500_lobs.py, test_1600_longs.py, and test_2500_lobs_async.py. Done means cached statements return the expected CLOB or LONG values across the reported query orders and pass those tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Version: python-oracledb 26.1.0, and also the current main (26.2.0b1, commit 27132e11, 2026-11-12), thin mode, Python 3.14, Linux.

Database: Oracle Database 23ai Free (23.26), 21c XE and 18c XE. It reproduces the same way on all three.

What happens

A query runs once without a type handler. The same SQL then runs on a new cursor whose outputtypehandler returns cursor.var(oracledb.DB_TYPE_LONG, ...) for the CLOB column. That second fetch misreads the reply, and the error depends on the columns around the CLOB:

query (plain first, then with the handler) default statement cache stmtcachesize=0
SELECT TO_CLOB('lob text') FROM dual DPY-5000: internal error: unknown protocol message type 40 ok
SELECT TO_CLOB('lob text'), DATE '2026-11-04' FROM dual ValueError: year must be in 1..9999, not -10062 ok
SELECT DATE '2026-11-04', TO_CLOB('lob text') FROM dual DPY-5000 ok
SELECT TO_CLOB('lob text'), 1.5 FROM dual DPY-5015: encoded number data too long (40 bytes) ok
SELECT TO_CLOB('lob text'), 'abc' FROM dual UnicodeDecodeError ok

If the handler is there on the first execute of the SQL, or the statement cache is off, every case returns the expected row.

Reproducer

import oracledb

DSN = "host:1521/service"  # any 12c+ database; queries DUAL only


def clob_as_long(cursor, metadata):
    if metadata.type_code is oracledb.DB_TYPE_CLOB:
        return cursor.var(oracledb.DB_TYPE_LONG, arraysize=cursor.arraysize)
    return None


sql = "SELECT TO_CLOB('lob text') FROM dual"
for cache in (20, 0):
    conn = oracledb.connect(user="...", password="...", dsn=DSN, stmtcachesize=cache)
    conn.cursor().execute(sql).fetchone()          # 1. plain: LOB locator
    cur = conn.cursor()
    cur.outputtypehandler = clob_as_long           # 2. same SQL, now as LONG
    try:
        cur.execute(sql)
        print(cache, "ok", cur.fetchone())
    except Exception as exc:
        print(cache, "fails:", type(exc).__name__, exc)
    conn.close()

Output:

20 fails: InternalError DPY-5000: internal error: unknown protocol message type 40 ...
0 ok ('lob text',)

Expected

('lob text',) in both cases, as with the cache off.

The reverse order is wrong too, silently: run the SQL first with the CLOB→LONG handler, then on a new cursor without a handler (or with a handler that leaves the CLOB alone), and the CLOB column comes back as str instead of a LOB.

Cause

In MessageWithData._preprocess_query() (src/oracledb/impl/thin/messages/base.pyx), when the output type handler differs from the one used for the statement's last fetch, the fetch variables are rebuilt for the new handler, but _requires_define isn't set. The statement is cached, so no new describe arrives either, and the database keeps returning the LOB columns in the form the last define asked for. The client then decodes them in the form the new fetch variables expect.

Setting _requires_define there isn't enough. On a cached cursor it sends a define without an execute, and the fetch fails with ORA-01002. The fix in the attached PR clears the cursor instead, as _process_error_info() already does for ORA-00932, but only when the statement has LOB columns (_no_prefetch). The statement is then parsed, described and defined again, and the fetch variables come from the new describe. With the fix, all 15 combinations (3 orders × 5 queries) pass on 23ai, 21c and 18c, and tests/cursor, tests/data_types/test_1500_lobs.py, test_1600_longs.py and test_2500_lobs_async.py pass against 23ai (597 passed, 8 skipped).

Lenguaje dominante
Python
Estrellas
458
Forks
123
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de oracle/python-oracledb

Todos los issues de oracle/python-oracledb

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.