Skip to main content

Asset Migrations and Snapshot

Summary​

Source-backed account of how the Asset Service database schema is versioned: a single initial migration, its designer and model snapshot, the rollback method it declares, and the constrained startup path that applies it.

Audience​

Backend engineers, database reviewers, architects, QA, support, operations, security reviewers, and product owners.

Overview​

The schema is created by exactly one authored migration, InitialAssetSchema. Its Up method builds all seven tables together with every index and the two intra-aggregate foreign keys; its Down method drops all seven. A designer file and a model snapshot accompany it, and no subsequent migration exists — the schema has had no source-tracked evolution beyond its initial creation.

Confirmed persistence behavior​

  • One authored migration. InitialAssetSchema is the only migration in source. It is accompanied by one designer file and one model snapshot (AssetDbContextModelSnapshot).
  • Initial schema scope. The migration's Up creates all seven tables — the asset aggregate, its assignment-history and document-reference children, the audit and timeline evidence tables, and the outbox and processed-event messaging tables — along with all configured indexes and the two required cascade foreign keys inside the aggregate.
  • Naming convention. Migrations use a timestamp-prefixed PascalCase name.
  • No subsequent evolution. There are no follow-on migrations; the model snapshot represents the same initial shape.
  • Provider annotations. The snapshot records the Npgsql PostgreSQL provider, including identity-column configuration for the numeric compatibility identity, and a model ProductVersion of 8.0.13.
  • Rollback method present, untested in source. The Down method exists and drops all seven tables, but there is no evidence in source that a rollback has been executed or tested.
  • Startup migration behavior (Development only). On startup the service applies pending migrations automatically only in the Development environment, and only when a skip-migrations gate is not set. In other environments the service does not self-migrate on startup. (Behavior described; the operator command is intentionally not reproduced here.)
  • Compatibility implication. The migration establishes the numeric compatibility identity as a database identity column at runtime, which the backfill path later overrides to insert legacy values verbatim.

Classification​

Implemented single-migration schema with a present-but-unverified rollback path and Development-only automatic application.

Requires confirmation​

  • Production migration ownership and execution path are out of source and require confirmation.
  • Whether the Down rollback has been validated against real data.
  • Any zero-downtime or online-migration strategy — no such evidence exists in source.

Diagram​

See Also​

Keywords​

  • Asset migrations
  • Model snapshot
  • Draft database documentation

Source References​

  • microservices/src/asset-service/Infrastructure/Migrations/20260707123634_InitialAssetSchema.cs
  • microservices/src/asset-service/Infrastructure/Migrations/AssetDbContextModelSnapshot.cs
  • microservices/src/asset-service/Program.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly