Custom Extensions showcase — guide + demo products + CI validation starter

[drzacharysmith68]

SchemaSmith has a customization layer that doesn't get nearly enough airtime: Extensions. You can embed any structured JSON metadata at every level of a schema definition — tables, columns, indexes, foreign keys, check constraints, statistics, full-text indexes, XML indexes, and indexed views. That metadata round-trips through extraction and quenching untouched, and it's available to your own scripts via the {{TableMetadata}} and {{IndexedViewMetadata}} tokens. So your schema files can become the source of truth for things the tools don't directly manage — and a single custom script can turn that metadata into real work.

Today there's no showcase for this. This issue tracks building one: a guide, working demo products, and an optional CI validation pattern. Contributions and use-case ideas are welcome — see the note at the bottom.

What you can do with Extensions (idea starters):

• Replication topology — mark which tables replicate, where, and how; generate the replication setup from the schema
• Data dictionary — business names, descriptions, sensitivity levels, data owners — queryable, and always in sync with the schema
• Column obfuscation rules — how to sanitize production data for dev/test
• Team ownership — which team owns which tables
• BI / reporting access — which tables and columns are exposed downstream
• Code-generation inputs — metadata that drives stored-procedure or script generation

Any platform — SQL Server, PostgreSQL, or MySQL. Some use cases are naturally cross-platform (a data dictionary works the same everywhere); others are engine-specific (replication setup is a SQL Server example). A demo for one engine, or parallel demos across all three, are equally welcome. We expect to end up with several realistic examples rather than one — people often need a demo close to their own situation before the pattern clicks, so variety is the point.

Two worked demos we're planning (and would love community takes on):

• Data dictionary (cross-platform) — table-level BusinessDomain / DataOwner / Description / RetentionPolicy and column-level BusinessName / Description / SensitivityLevel / DataSteward. A custom script populates a queryable DataDictionary table on every quench.
• Replication setup (SQL Server) — table-level ReplicationEnabled / ReplicationTarget / ReplicationMode and column-level ReplicateColumn / ConflictResolution. A custom script reads {{TableMetadata}}, walks the tables marked for replication, and generates the DDL.

Validating your Extensions in CI (optional, for teams that want enforcement):
SchemaSmith's generated schema validates the structure of your tables (Name, Columns, Indexes, …). Your custom metadata is yours to shape, so it's validated in a second pass: a JSON Schema you write that's permissive everywhere (additionalProperties: true) except inside your own Extensions blocks, where you lock down required fields, allowed values, and types at each level. Wire it into CI with the same GrantBirki/json-yaml-validate action the SchemaSmith demos already use. This issue includes shipping a starter .schema template you can copy and fill in only for the levels you use.

The technical foundation is already in place — no tool changes needed:

• Extensions accepts any valid JSON on 9 entity types
• Custom metadata is preserved through extraction round-trips
• {{TableMetadata}} serializes the full table graph (including all Extensions at every level) for use in any custom script
• Base schema validation already treats Extensions as "accept anything," leaving the strict rules to your second-pass schema

Want to get involved? Share the Extensions use case you'd build (or already have), or contribute a demo on any engine. We're building these showcases ourselves too, so maintainers may adapt a contributed demo — or build a companion — to round out the set; we'll talk it through on the issue either way.

[drzacharysmith68]

Status update (2026-06-28): Splitting this into two streams so the most immediately useful half moves sooner.

Now prioritized — CI validation. Working, runnable JSON-Schema validation examples wired directly to the demo packages on all three engines (SQL Server, PostgreSQL, MySQL), plus a starter .schema template you can copy to lock down your own Extensions fields in a second pass. This is the piece teams can adopt today, so it's moving up the queue. The guide already describes the pattern (Testing and Validation / CI/CD Integration); this adds the example you can actually run against the demos.

Still planned — the broader showcase. The guide walkthrough and worked demo products (data dictionary, replication setup, and more). Contributions and use-case ideas remain very welcome — share the Extensions use case you'd build (or already have), on any engine.

[drzacharysmith68]

Status update (2026-07-04): this is landing in the free training course as step-by-step labs, not as static demos.

The CI-validation half is done — as a free, runnable public lab. The second-pass Extensions validation pattern (a JSON Schema that stays permissive everywhere except your own Extensions blocks, where it locks down required fields and allowed values — wired into CI with GrantBirki/json-yaml-validate, no database) now ships as Course 6, Module 3 — "CI schema validation & Extensions governance" on the free training site (learn.schemasmith.com). It walks the whole thing at both table and column level, and the runnable lab is in the repo: Demos/Learn/course6-module-03, certified on SQL Server, PostgreSQL, and MySQL.

The data-dictionary showcase is coming the same way — a training lab. Rather than a finished-demo drop, it'll be step-by-step: embed business metadata in Extensions, read the whole table graph via the {{TableSchema}} token, and generate a queryable DataDictionary on every quench, on all three engines. A lab you can run and adapt teaches the pattern better than a static demo — and it's free and public like the rest.

What's left on this issue:

• The guide walkthrough — an "Extensions in action" section in the end-user docs that ties the pieces together.
• A SQL Server replication-topology example — the engine-specific counterpart (mark tables for replication in Extensions, generate the setup DDL).
• Your use cases — the contribution ask stands: share the Extensions use case you'd build (or already have), on any engine. Data dictionary, obfuscation rules, ownership, BI exposure, code-gen inputs — variety is the point.