Fix #4614: keep mt_version as integer for IRevisioned (V8) documents

[jeremydmiller]

Problem

Users upgrading Marten 8 → 9 see their SingleStreamProjection aggregate document tables silently migrate mt_version from integer to bigint. The widening was unintentional — leftover from #3733 (which widened RevisionColumn to MetadataColumn<long>), then partially reverted in #4533 (IRevisioned.Version went back to int but the column itself stayed bigint).

The user-visible symptom is an ALTER TABLE … ALTER COLUMN mt_version TYPE bigint showing up on every aggregate document table at first V9 apply, with no real reason — IRevisioned-backed documents track a per-stream version that comfortably fits Int32 and was the V8 default.

Fix

The version column width now varies by the document's interface:

Interface	Column	Used by
IRevisioned (int)	integer	SingleStreamProjection aggregates — version comes from mt_streams.version (per-stream counter)
ILongVersioned (long)	bigint	MultiStreamProjection-projected documents — version is the global event sequence number, can exceed Int32

Discriminator is the interface choice, not the projection kind. This decouples the column-width decision from the existing UseVersionFromMatchingStream flag (which is about SQL semantics — where the version comes from — and shouldn't also control DDL).

Migration matrix

Non-destructive in both directions:

Actual	Desired	Action
integer	integer (IRevisioned)	no-op — the headline fix; V8 → V9 stops force-widening
integer	bigint (ILongVersioned)	ALTER … TYPE bigint — legitimate V8 → V9 widening preserved
bigint	integer (IRevisioned)	no-op — tolerate existing 9.x columns; no USING ::integer force-narrow that could silently truncate
bigint	bigint (ILongVersioned)	no-op
uuid	either	drop + recreate at desired width

Refusing the bigint → integer narrowing is the safety call. A USING mt_version::integer cast would truncate any out-of-range value without Postgres scanning to verify, and an IRevisioned-backed table that's been on 9.x for a while has no real reason to need its column narrowed — the wider column is harmless on disk.

Implementation

• RevisionColumnInt32 sibling of RevisionColumn — integer column, integer parameter type, integer-aware migration policy.
• RevisionArgumentInt32 sibling of RevisionArgument for the codegen path.
• DocumentMetadataCollection.Revision gets an internal setter so VersionedPolicy.Apply() can swap to the Int32 variant when IRevisioned is detected on the document type.
• DocumentRevisionBinder accepts a column NpgsqlDbType so BindParameter and WriteToBulkAsync emit integer/bigint to match the column. Read side stays as long — Npgsql widens int → long via the field-value handler.
• ClosedShape{Insert,Update,Upsert}Operation: revision parameter slots now bind with the binder's ColumnDbType (integer for IRevisioned, bigint for ILongVersioned) so the CASE expression's branches type-align with the target column. Postgres won't auto-narrow on the strict VALUES path, so this match has to be exact.
• DocumentTable.SelectColumns matches RevisionColumnInt32 explicitly (sibling, not subclass of RevisionColumn) so the version slot stays canonical in the SELECT projection.

Tests

8 tests in src/CoreTests/Bugs/Bug_4614_revision_column_int_for_IRevisioned.cs:

• Fresh IRevisioned table → integer column.
• Fresh ILongVersioned table → bigint column.
• V8 integer + IRevisioned → no migration (headline regression).
• V8 integer + ILongVersioned → widens to bigint (legitimate path preserved).
• 9.x bigint + IRevisioned → tolerated, no force-narrow (data-safety guarantee).
• IRevisioned round-trip insert + update + read on integer column.
• ILongVersioned round-trip insert + update + read on bigint column.
• SingleStreamProjection<IRevisionedDoc> end-to-end through the inline projection path on the integer column.

Regression sweep

All clean:

• CoreTests: 424 passed
• DocumentDbTests: 999 passed
• EventSourcingTests: 1358 passed

🤖 Generated with Claude Code