Generate current and end-dated views

Persistent staging tables and Data Vault satellites keep every version of a row over time. To read them you usually write the same “latest row per key” or “valid from and to” SQL by hand, on every table. DeltaVault can generate those two views for you and keep them in step with the base table.

What the two views are

• A current view returns the latest version of each row: one row per key, newest load wins. Use it when you want the data as it stands now, without the history columns getting in the way.
• An end-dated view adds a validity range to each version: an effective-from and an effective-to, so you can ask what a row looked like on a given date. DeltaVault closes each version’s end date at the moment the next version begins.

Both are regular views over the base table, so they always reflect the latest data.

Which tables are eligible

The two toggles appear only for tables that carry history:

• Persistent staging tables, and
• Satellite-family tables in a Data Vault (satellites, link satellites, reference satellites, and business satellites).

For any other table the toggles stay hidden, because there is no version history to collapse or to end-date.

Turn the views on

1. Open the table and, on its Details tab, expand the Render options card.
2. Switch on Generate current view to generate the current view, and Generate end-dated view to generate the end-dated view. You can turn on either, both, or neither.

DeltaVault adds the generated view objects to your catalog next to the base table.

Turn the views on for every table at once

Setting both switches on every satellite by hand does not scale past a handful of tables. Open Settings, then Derived History Views, and turn on Generate current views by default or Generate end-dated views by default. Every history-bearing table that has not chosen for itself follows the default.

A table’s own choice always wins. If someone switched Generate current view off on one satellite, turning the organization default on leaves that satellite alone: an explicit no stays a no. The render options panel tells you which is which, showing an Organization default badge on a table inheriting the default and a Table override badge on one that has chosen.

Both switches decide what gets created, and nothing else. Turning one off, whether it is the organization default or a single table’s own choice, never removes a view that already exists. That is deliberate: a generated view is a real object in your catalog with its own lineage and its own file in your repository, and one switch should not delete hundreds of them across an estate, quietly, one at a time as people happen to edit unrelated tables.

The cost of that promise is worth knowing up front. If you turn a switch off on a table whose view has already been generated, that view stays in your catalog and every build keeps generating it. Nothing about the object changes. The render options panel tells you when you are in that position: it names the view, says it still exists and is still generated, and offers to remove it there and then.

Name the generated views

The same settings section carries three naming fields:

• Current view suffix is appended to the base table’s name to name its current view. The default is _current, so sat_customer gets sat_customer_current.
• End-dated view suffix does the same for the end-dated view. The default is _edt.
• Default end date is the far-future date stamped on the open row of an end-dated view, written as year, month and day. The default is 9999-12-31.

Suffixes take letters, digits and underscores only. A dot would split the view’s name into an extra part, and a quote would break both the generated SQL and the file DeltaVault writes for the view in your repository.

Saving a name renames nothing that already exists. A new suffix names the views generated from now on; views already in your catalog keep the name they were created with. Renaming a view that is already deployed moves a real warehouse object and the file that describes it, so it is never something a settings save does behind your back.

Apply the settings to tables you already have

Both promises above leave the same gap: the settings are right and your existing tables have not caught up. Apply to existing tables, at the bottom of the same settings section, closes it.

1. Work on a branch. The sweep writes to every eligible table at once, and that belongs in a change somebody can review before it reaches your main line.
2. If you want existing views renamed to match a changed suffix, tick Also rename existing companion views to match the suffixes above. It is off by default.
3. Click Apply defaults. Nothing is written yet: DeltaVault plans the whole run first and tells you how many views it would create, how many it would rename, and how many existing views it is leaving alone.
4. Read those numbers, then confirm. DeltaVault reports what the real run actually did.

Two things are worth knowing before you run it:

• Nothing is ever deleted. The sweep creates and renames. Any view no longer asked for, whether the organization default turned off or the table itself said no, appears in the report as left alone and stays in your catalog.
• A large estate may take more than one run. Renaming is capped per run, so a single pass cannot grow beyond what DeltaVault can safely apply at once. The report tells you how many renames are left, and running it again picks up where it stopped.

System-generated, and how to customize

A generated view is system-managed: DeltaVault writes its SQL for you and keeps it in step with the base table. In the catalog tree these views carry a lock icon and a System-generated badge, and their detail pane header reads System-generated, read-only beside the Customize button.

When the generated SQL is not quite what you need:

1. Open the view and choose Customize.
2. DeltaVault freezes the current generated SELECT into the view as your own editable copy. The view is now yours: the caption and badge disappear, and DeltaVault stops managing it.

To hand a customized view back to DeltaVault, choose Reset to system-generated. The view returns to being managed and tracks the base table again. Customize and Reset are available to editors working on a branch.

Remove a generated view

Because no switch deletes anything, removing a generated view is its own act. Open the view and choose Remove view, or use the removal offered beside the switch in Render options on the base table. Either way you get the same confirmation, and it is worth reading rather than clicking through.

Removing a view does two things at once. It takes the view out of DeltaVault: the catalog row goes, and so does the file that describes it in your repository. It also turns generation off for that kind on the base table, so the next build does not simply create the view again. Those two have to happen together, which is why removal is one action rather than a delete followed by a switch you might forget.

The view already deployed to your warehouse is not dropped. DeltaVault stops generating it and stops tracking it, but the object itself keeps answering queries until somebody drops it by hand. If you want it gone from the warehouse, that is a deliberate step you take there.

A customized view is out of reach of all this. Once you have taken a view over, its definition belongs to your team, so DeltaVault will not remove it: reset it to system-generated first, or delete it from the catalog like any other view you wrote. Removal is available to editors working on a branch.

There is one case where DeltaVault removes a generated view without being asked, and it is not a preference. If the base table stops carrying history, because its kind or its layer changed, or because a satellite became an effectivity variant that already dates its own rows, the generated view has nothing left to read and DeltaVault takes it out on the next change to that table. The warehouse object survives that too.

Where the views show up

• Catalog tree: the generated views sit beside the base table, marked with the lock icon and the System-generated badge.
• Preview tab: open a generated view and switch to Preview to read the SQL DeltaVault generates for it.
• Lineage tab: the view lists its base table as a source, so lineage walks and impact analysis reach through the view to the table it reads.