Templates reference

The templates documented in this section are examples. They ship as part of ADL’s sample solutions to illustrate one way of generating code for a given pattern. They are not a fixed library that defines “the right answer” for any data solution — and they’re not the only way to use ADL.

Templates are configurable

A template in ADL is just a Handlebars file in your project. You can:

• Use the bundled examples as-is when they match your project’s technology and approach.
• Modify them in-place — adjust naming, add columns, change syntax for a different SQL dialect, swap out a hashing algorithm, anything.
• Write your own from scratch for output formats or platforms ADL doesn’t already ship.

The same metadata can drive any text-based output. If you can write the target code by hand, you can write a template that generates it — SQL of any flavour, PySpark, Python, dbt models, Terraform, documentation, deployment scripts, or whatever else your stack needs.

Templates are tied to specific samples and designs

Each template documented here is part of a specific sample solution, and reflects the choices that sample makes:

• Technology choice. SQL Server T-SQL, Snowflake SQL, PySpark notebooks. Templates are dialect-specific by necessity — the same Hub built for SQL Server doesn’t run unchanged on Snowflake.
• Methodology choice. Data Vault vs. dimensional, virtual data warehouse vs. physical data warehouse, Persistent Staging Area vs. landing-only. These pick a model of the world, and the templates implement that model.
• Opinionated detail. Hash algorithm (MD5 vs. SHA), surrogate key construction, audit column naming, change-detection strategy, end-dating semantics. Two templates for the “same” object can differ on these and both be correct for their respective designs.

If a template makes a choice you disagree with — say, you’d prefer SHA-256 over MD5, or end-dated history over append-only Satellites — change it. The metadata stays the same; only the generated output changes.

How to read this reference

Browse the sub-sections to see what’s bundled. Each template page documents:

• Purpose and motivation — what the template is for and why it exists.
• Applicability — the technology and design pattern it targets.
• Implementation guidelines — how it works against the metadata, and the assumptions it makes.
• Considerations and consequences — the trade-offs baked into the template.
• Extensions — the metadata extensions and conventions the template reads.
• Code (where included) — the Handlebars source, for reference and adaptation.

Sections

• All-metadata templates — Templates that walk the whole project (control-framework registration, documentation, deployment scripts).
• Data object templates — staging and integration — Templates assigned to Data Objects to generate their physical tables.
• Data object mapping templates — staging and integration — Templates assigned to mappings to generate the code that moves data (stored procedures and views).
• No-metadata templates — bundled under nometadata/; small templates that don’t bind to specific project entities (sample-data seed scripts and similar).
• Extensions reference — under extensions/; patterns for using metadata extensions to drive template branching.
• Output types — Notes on the categories of code these templates generate.

For the broader concept of templates and code generation, see Templates & Code Generation.