BoxLang + Oracle: bulkOperationsSpec INSERT...RETURNING + migratorSpec rename errors

[bpamiri]

Describe the bug

On BoxLang × Oracle, five specs error. Lucee 6 and Lucee 7 skip Oracle entirely (the matrix records 0 pass / 0 fail / 0 err because #2663 put Oracle on a soft-fail track), so BoxLang is the only engine currently exercising the Oracle datasource — and these are the resulting errors.

Failing specs

wheels.migrator.migratorSpec :: renames c_o_r_e_levels -> wheels_levels and c_o_r_e_migrator_versions -> wheels_*
  → ORA: Closed statement

wheels.model.bulkOperationsSpec :: inserts multiple records in a single call
  → ORA: returning clause is not allowed with INSERT and Table Value Constructor

wheels.model.bulkOperationsSpec :: inserts records with auto timestamps
  → ORA: returning clause is not allowed with INSERT and Table Value Constructor

wheels.model.bulkOperationsSpec :: skips timestamps when timestamps argument is false
  → ORA: no statement parsed

wheels.model.bulkOperationsSpec :: handles single record insertion
  → ORA: no statement parsed

Reproduction

tools/test-matrix.sh boxlang oracle

Likely root causes

1. bulkOperationsSpec (4 errors) — Oracle does not accept INSERT ... VALUES (...), (...) RETURNING ... (multi-row values constructor with RETURNING). The bulk-insert code path needs an Oracle-specific branch (likely INSERT ALL INTO ... SELECT * FROM dual per row, or per-row INSERT in a loop, plus serial RETURNING). "No statement parsed" on the single-record cases suggests the generated SQL is malformed in a different way for those — investigate after the multi-row case is fixed.

2. migratorSpec rename (1 error) — "Closed statement" usually means the JDBC statement object was closed before result extraction. Oracle's JDBC driver is stricter about statement lifecycle than other drivers. The rename path may be reusing a closed statement, or the rename is triggering an unsupported Oracle DDL that fails silently and leaves the statement in a bad state.

Evidence

Compat-matrix run 25978222394 (develop, 2026-05-17):

• boxlang/oracle: 5 errors (these specs)
• lucee6/oracle: 0 / 0 / 0 (datasource skipped — ci: Oracle datasource broken across all engines — Invalid URL, missing DBMS_LOCK, constraint cleanup #2663 still partially open)
• lucee7/oracle: 0 / 0 / 0 (same)

So BoxLang is currently the only engine that catches these. Worth fixing both because (a) the bulk-insert RETURNING constraint is a real Oracle limitation that any engine will hit once Oracle is restored to the hard-gated set, and (b) the migrator rename error suggests a JDBC lifecycle bug worth chasing on its own.

Expected behavior

Both specs pass on BoxLang × Oracle, and continue to pass once Lucee runs Oracle again.

Related

• Parent: Core test suite has high failure/error rate on BoxLang (35 failures, 125 errors, 3526 passing) #2649 (BoxLang compat rollup)
• Adjacent: ci: Oracle datasource broken across all engines — Invalid URL, missing DBMS_LOCK, constraint cleanup #2663 (Oracle datasource — restore-to-hard-gated work; complementary, not blocking)

Desktop

• CFML Engine: BoxLang
• Database: Oracle

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

model — the bulk-insert path in vendor/wheels/model/ is responsible for 4 of the 5 errors. The 5th error is in migrator (rename path in vendor/wheels/migrator/). The Oracle-specific reasoning belongs in .ai/wheels/cross-engine-compatibility.md.

Fix sketch

Two distinct fixes are needed:

1. Bulk insert RETURNING (4 errors) — likely in vendor/wheels/model/adapters/Oracle.cfc or wherever the bulk-INSERT SQL is generated for Oracle. Oracle does not support multi-row INSERT ... VALUES (...), (...) RETURNING .... The fix is an Oracle-specific branch in the bulk-insert SQL generator: either INSERT ALL INTO ... SELECT * FROM dual for the multi-row case, or per-row INSERT in a loop with serial RETURNING. The "no statement parsed" errors on single-record cases suggest a related SQL-malformation that should be inspected after the multi-row case is wired correctly.

2. Migrator rename "Closed statement" (1 error) — likely in vendor/wheels/migrator/ rename-table path. Oracle's JDBC driver is stricter about statement lifecycle than MySQL/Postgres drivers. The fix is to inspect the statement-handling sequence in the rename code path: either an unsupported Oracle DDL is silently failing and leaving the statement in a bad state, or a statement object is being reused after close. Likely needs explicit statement re-acquisition before result extraction.

Reproduction (do not run in triage; propose-fix should run this):

tools/test-matrix.sh boxlang oracle

Confidence: medium

Auto-downgraded from high because (a) cross-engine concern (BoxLang × Oracle behavior diverges from other DBs), (b) migrator subsystem is involved alongside model, and (c) two distinct failure modes touching two layers reduces the chance of a single mechanical fix.

<!-- wheels-bot:triage:2745 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2749

Spec: vendor/wheels/tests/specs/model/oracleBulkInsertSqlSpec.cfc — failing → passing (5/5)
Implementation: vendor/wheels/databaseAdapters/Base.cfc, vendor/wheels/databaseAdapters/Oracle/OracleModel.cfc, vendor/wheels/model/bulk.cfc

Scope: only the 4 bulkOperationsSpec errors (the model-layer half of this issue). The 5th error — migratorSpec :: renames c_o_r_e_levels failing with ORA: Closed statement — touches vendor/wheels/migrator/**, which falls under the bot's safety-net policy requiring human-in-the-loop review before code is written. That part remains open under this issue as a follow-up.

A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.