Data Delivery

A table's DataDelivery is either a single object (the form above, unchanged) or an array of independently-gated deliveries. Each array entry is a full DataDelivery object — its own ContentFile, MergeType, MergeFilter, and the rest. This is the mechanism behind three common patterns:

• Environment-gated seed/test data. Ship fixture or test rows that only land in dev or test databases.
• Per-environment variants. A rich dataset for dev, a minimal reference set for production — same table, mutually exclusive gates.
• Additive patch slices. Several deliveries with disjoint MergeFilters, each covering its own slice of the table, all applying together.

Unlike the single-match variant pattern used elsewhere in the schema package, data deliveries are not "one match wins": at quench time, every delivery whose ShouldApplyExpression passes applies, in declared order. That's what makes additive patch slices possible — and it's why an array of two or more deliveries requires a ShouldApplyExpression on every entry (an ungated entry alongside others would always apply, defeating the point of gating); loading an array that omits one on any entry fails with a clear error before any deployment work begins.

Pattern 1 — environment-gated seed data (SQL Server)

A single delivery can carry a ShouldApplyExpression on its own — no array required. This table's fixture rows only merge into databases whose name ends _dev or _test; everywhere else, delivery is skipped for this table.

"DataDelivery": {
  "ContentFile": "data/dbo.TestFixtures.tabledata",
  "MergeType": "Insert/Update/Delete",
  "MatchColumns": "[FixtureId]",
  "ShouldApplyExpression": "DB_NAME() LIKE '%_dev' OR DB_NAME() LIKE '%_test'",
  "VariantName": "Dev/test fixtures"
}

Pattern 2 — per-environment variants (PostgreSQL)

The two gates are mutually exclusive, so exactly one variant applies per target — a full catalog in dev, a lean reference set everywhere else — from one table definition.

"DataDelivery": [
  {
    "ContentFile": "data/public.product_catalog.dev.tabledata",
    "MergeType": "Insert/Update/Delete",
    "MatchColumns": "product_id",
    "ShouldApplyExpression": "current_database() = 'app_dev'",
    "VariantName": "Rich dev catalog"
  },
  {
    "ContentFile": "data/public.product_catalog.prod.tabledata",
    "MergeType": "Insert/Update",
    "MatchColumns": "product_id",
    "ShouldApplyExpression": "current_database() <> 'app_dev'",
    "VariantName": "Minimal prod reference set"
  }
]

Pattern 3 — additive patch slices (MySQL)

Both deliveries share the same gate — on app_main, both apply. Each is scoped to its own Category slice by MergeFilter, so the two additive deliveries never fight over the same rows.

"DataDelivery": [
  {
    "ContentFile": "data/StatusCodes.core.tabledata",
    "MergeType": "Insert/Update/Delete",
    "MatchColumns": "StatusCodeId",
    "MergeFilter": "Category = 'Core'",
    "ShouldApplyExpression": "DATABASE() = 'app_main'",
    "VariantName": "Core status codes"
  },
  {
    "ContentFile": "data/StatusCodes.regional.tabledata",
    "MergeType": "Insert/Update/Delete",
    "MatchColumns": "StatusCodeId",
    "MergeFilter": "Category = 'Regional'",
    "ShouldApplyExpression": "DATABASE() = 'app_main'",
    "VariantName": "Regional status codes"
  }
]

Gate evaluation, logging, and WhatIf

SchemaQuench evaluates every delivery's gate against the target once per quench, before any content file is read, and every delivery whose gate passes applies — not just the first match. A delivery whose gate evaluates false is logged as skipped and never touches the table; a delivery whose gate expression itself errors aborts the deployment (fail-closed), the same way a folder-level gate does.

A gated-off delivery is logged as skipped, distinct from a delivered or a failed one — the message names the table and the delivery's VariantName, so a scan of the progress log tells you which deliveries ran and which were gated out.

Gate evaluation also runs during WhatIf, so a dry run reports the same deliver-vs-skip decisions a real quench would make. Skipped deliveries are still logged individually with their VariantName, exactly as in a real run; applied deliveries are reported as a single Would DELIVER: <table> line for the table, not broken out per delivery.

The Insert/Update/Delete CASCADE-FK check considers only deliveries whose gate is currently passing — a Delete variant that's gated off this run can't abort the deployment over a CASCADE FK it will never execute.