[hemju]

Problem

On an Oracle database with MAX_STRING_SIZE=EXTENDED, the 1.1.0 baseline migration stops at statement 28 of V1__baseline.sql:

ORA-12899: value too large for column "IDLE_SORT" (actual: 2058, maximum: 2000)

threadmill_concurrency_groups.idle_sort was declared RAW(2000). Oracle sizes NLSSORT(...) as if the sort could be linguistic, even with 'NLS_SORT = BINARY' in the call. For a VARCHAR2(256 BYTE) key that is RAW(2000) under STANDARD but RAW(2058) under EXTENDED. CI runs only STANDARD, which is the 23ai Free default, so this never showed up there.

Fix

• idle_sort now takes its type from the expression instead of declaring one. Under STANDARD the schema is identical to 1.1.0. The query and index are unchanged.
• OracleMigrationRunner.SUPERSEDED_CHECKSUMS accepts the 1.1.0 baseline checksum:
  • A completed 1.1.0 schema stays valid.
  • A schema stopped at statement 28 resumes with the corrected statement and stores the current checksum when it finishes, through both migrate() and emitPendingSql().
• The released 1.1.0 baseline is frozen as a test resource. A test checks that statements 1–27 and 29–35 match it byte for byte.
• Release prep for 1.1.1: version, changelog, upgrade notes and install snippets.

Verification

• Full Oracle suite (161 tests) on the CI Testcontainer, 23ai Free with STANDARD.
• Full Oracle suite, including the executed-plan tests, on 23ai Free switched to MAX_STRING_SIZE=EXTENDED (PDB open upgrade plus utl32k.sql) through -PoracleJdbcUrl. Sessions run with OPTIMIZER_FEATURES_ENABLE='19.1.0'. Before the fix, this setup reproduced the reported ORA-12899 exactly.
• New regressions:
  • releasedBaselineDiffersOnlyInTheStatementThatFailsUnderExtendedStringSize
  • releasedBaselineStoppedAtTheExtendedStringSizeFailureResumesAndRecordsTheCurrentChecksum
  • schemaCompletedByTheReleasedBaselineStillValidatesAndMigrates

Still open: a run on a real 19c database. No free 19c image exists. The first real 19c with EXTENDED is the deployment that reported this bug.