Repository navigation
Weasel 9.25.1
Skip 9.25.0 and take this one. It fixes a regression that refuses to create tables 9.24 accepted.
Full notes: Upgrading to 9.25
⚠️ The regression this fixes
#485 and #486 — one root cause, two symptoms.
9.25.0 began validating the names a table writes that are not database objects of their own — its columns, its primary key constraint, its check constraints (#468). It ran them through the provider's AssertValidIdentifier, which also enforces the length limit. Schemas that applied cleanly on 9.24 started throwing.
The names it rejected are entirely conventional. They are just long — which a wide composite primary key on a long table name produces easily:
pkey_mt_doc_bug_4679_catch_up_per_tenant_23505_tripdistance_tenant_id_id (72 chars)
Why the length rule did not belong there
Weasel's own code already said so. A object name the database truncates becomes unaddressable and drifts on every check afterwards — worth refusing. A local identifier is only emitted inside its own table's DDL and never addressed by name again, and TableDelta already compares both PrimaryKeyName and the primary key column list through TruncatedNameIdentifier precisely so a truncated one still matches.
Weasel was handling truncated local identifiers downstream while refusing to create them upstream. Those two positions could not both be right.
Migrator.AssertValidLocalIdentifier now applies the same safety rules with no length limit — a quote, a semicolon, a line break, leading or trailing whitespace are still rejected wherever they appear. The base implementation defers to AssertValidIdentifier, so a provider outside this repository keeps the stricter behaviour until it opts in.
The quiet half
#486 presented as a 23505 on pk_mt_event_progression during a Marten per-tenant daemon catch-up — an error naming a table with nothing to do with identifiers.
The rejection had aborted a projection's schema application. The daemon then ran against storage that was never created and failed downstream. The loud failure and the quiet one were the same rejection. If you saw anything strange on 9.25.0, rule this out before looking further.
Also in this release
Functions on MySQL and Oracle (#482) — the half of #450 that closed on its views and left this behind. Both catalogs store what their stored-procedure counterparts store, so comparison works the same way.
That completes the object type matrix apart from check constraints on Oracle, MySQL and SQLite (#488) — accepted by TableBase on all five providers and emitted by only two. Pre-existing rather than a 9.25 change, and tracked.
Upgrading from 9.24
Everything in 9.25.0 still applies — the identifier quoting changes, the column-name rewrite removal, the SQLite data-loss fix, the Oracle migration-path fix, and the one-time schema fingerprint re-evaluation. Read those notes too.