View families

Two families write views, and they were one family until they were split apart. They share a root named view and mean different things by it, which is the whole reason the split happened: a designer view carries a stored SELECT and a structured model, while a derived history view projects a window function over a base table and has no stored SELECT to read at all. Handing the second shape the first one’s contract meant handing it fields there was nothing honest to fill.

view

Templates: databricks/shared/create_view.jinja, databricks/data_mart/source_view.jinja, fabric/shared/create_view.jinja, snowflake/shared/create_view.jinja

Roots: view

The frozen SELECT contract, and one root is the whole of it. A table without a stored view definition gets a typed refusal rather than a hollow render.

The root carries both halves of the contract: the identity and frozen statement a simple body needs, and a structured model a body can compose its own layout from. hasStructuredSelect is the switch between them. When it is false there is no model to walk and the template emits selectSql verbatim.

Field	Type	Meaning
view.schema	string	The schema the view is created in.
view.name	string	The view’s name as authored.
view.nameSnakeCase	string	The name through the snake-case naming model (what the mart source view materializes as).
view.selectSql	string	The frozen SELECT statement with macro tokens resolved.
view.qualifiedName	string	The reference the CREATE OR REPLACE VIEW names, already quoted and already in the calling dialect’s form: a plain schema and name pair, a catalog-qualified literal for the deploy bootstrap, or the exec_sql concatenation form for the notebook.
view.hasStructuredSelect	boolean	Whether select, from and joins carry a model to compose from. False for a frozen SELECT, where the body emits selectSql as is.
view.isParameterised	boolean	Whether to emit the notebook parameter cell and wrap the statement in SET VARIABLE exec_sql plus EXECUTE IMMEDIATE. Branch on this, never on whether parameters.declarations is empty: an empty array is truthy in the template language.
view.parameters	object	The notebook parameter cell.
view.select[]	array	The projected column model, when the select is structured.
view.selectAll	boolean	True when the view projects no columns and the select list is *.
view.from	object?	The base relation model; null when there is none.
view.joins[]	array	The join model.
view.where[]	string[]	The filter predicates.
view.whereCount	number	How many predicates there are. Branch on this rather than on the array, for the same truthiness reason as isParameterised.

derived-history-view

Templates: databricks/shared/current_view.jinja, databricks/shared/effectivity_view.jinja

Roots: view, columns, base, partition_keys, effective_from, effective_to, default_end_date

The managed current and effectivity views over a history table. Here view is identity only, {schema, name} and nothing more, and the projection arrives as six flat roots beside it. The root names are flat and snake-cased because this shape predates the loading vocabulary.

Field	Type	Meaning
view.schema / view.name	string	Identity only: the schema and name the view is created as. There is no selectSql on this family.
base.schema / base.name	string	The base history table (persistent staging or a satellite) the view projects over.
columns	string[]	The base table’s column names, in base order (the projection list).
partition_keys	string[]	Window partition keys. Resolution order: the resolved parent hub or link hash key (satellite bases), then table-level business-key columns, then column-flagged business keys, then primary keys. An empty result makes the Build skip the view with a warning.
effective_from	string	The load-date column the window orders by, from the naming profile.
effective_to	string	The computed effective-to column’s alias. A constant, and its value is dv_row_load_edts rather than the root’s own name.
default_end_date	string	The open-ended row’s end date, from the naming profile, defaulting to 9999-12-31.