Upgrading to 9.38

9.38 is one fix, on Oracle, in three parts: an identity column could not be created, was never read back, and made its schema undroppable. If you use AutoIncrement() on Oracle, or worked around it by writing the identity clause into a column's type string, this is the release that makes it settle.

Notes published after the fact

9.38.0 went to NuGet on 2026-10-04 without a tag, a GitHub release or this page. The packages are real and unchanged; only the paperwork was missing. Nothing here is new behaviour since then.

Coming from 9.37?

One deliberate change in what a migration reports: IsAutoNumber now counts towards TableColumn equality, so adding or dropping identity on an existing Oracle column is finally seen as a difference. If you carried the identity clause inside a column's type string as a workaround, drop that workaround and call AutoIncrement() — otherwise the type string still cannot match what the catalog reports and the column keeps drifting.

Oracle: an identity column round-trips

#667.

GENERATED BY DEFAULT AS IDENTITY is its own clause rather than part of the column type, and neither the DDL side nor the read side accounted for that.

The emitted DDL was invalid. Declaration() put the clause after the null constraint:

NUMBER(10) NOT NULL GENERATED BY DEFAULT AS IDENTITY   -- ORA-03076

Oracle's grammar is column datatype [DEFAULT expr | identity_clause] [inline_constraint ...] — the identity clause stands in the DEFAULT slot. They are alternatives, not additions. So AutoIncrement() could not create a table at all, and callers worked around it by writing the clause into the column's type string, where it can never match what the catalog reports back. An identity column is also implicitly NOT NULL, and Oracle rejects an explicit NULL on one.

Identity was never read back. ColumnSql did not select IDENTITY_COLUMN and ReadColumn never set IsAutoNumber, so every column came back non-identity.

A schema containing an identity column could not be dropped. ResetSchemaAsync enumerated every sequence in the schema, including the system-generated ISEQ$$_… one behind an identity column. Oracle refuses to drop one of those directly — ORA-32794 — which is not in the "already gone" family, so it propagated and left the teardown unfinished. One identity column anywhere in the schema was enough to make the schema undroppable. That sequence needs no drop of its own: it goes with its table, and the table drop already runs first. The filter is on ALL_OBJECTS.GENERATED rather than on the ISEQ$$ name, which is a convention rather than a contract.

Why the equality change is only safe with the reader

Comparing a flag that is never read back would make every identity column drift forever — which is precisely the bug being fixed. The equality change and the reader go together; neither is correct alone. GetHashCode is deliberately unchanged, since unequal objects may share a hash.

A unit test had encoded the bug

The test asserting the old clause order never touched a database, so it passed happily while the string it asserted was rejected by Oracle. It is updated, with a note saying why.