Skip to content
Contact us Go to Customer Portal
  • There are no suggestions because the search field is empty.

Persist Validity (Project)

Applies to
Platform: Microsoft SQL Server · Snowflake · Snowflake dbt · Databricks · Databricks dbt · Fabric Lakehouse · Fabric Warehouse · Oracle
Architecture: Data Store · Data Vault · Dimensional · Data Mart

Persist Validity (PersistValidity) decides whether BG_ValidToTimestamp is a column of the historized tables or is calculated in the result views. It applies to every historized model object of the project.

Available since Generator 2.2.

Values and defaults

  • true: the tables store BG_ValidToTimestamp, and the loaders write it.
  • false: the tables have no BG_ValidToTimestamp column, and the result views calculate it.

The default is false on Microsoft SQL Server and Oracle and true on all other platforms. Set the value in the Historization group of the Additional Settings in Project Settings.

Effect on generated output

With true, the loader inserts each new version with End of Universe. In the same transaction it sets the end of the previous current version of each loaded key. dbt models do this in the post-hook bg_close_validity_merge. Both values give the same BG_ValidToTimestamp in the result views; Generated versus result-view behavior shows the details.

With Create Result Views set to false, set Persist Validity to true. Otherwise validation reports error ID-10064 for each historized Store Entity, Entity and satellite.

Example

A Store Entity on Microsoft SQL Server with Persist Validity true is loaded at 10:00, 11:00, 12:00 and 13:00 UTC on 2026-10-27. Customer 1 has a new address at 11:00 and at 13:00. The table stores:

CUSTOMER_ID  BG_ValidFromTimestamp    BG_ValidToTimestamp
1            1900-01-01 00:00 +00:00  2026-10-27 11:00 +00:00
1            2026-10-27 11:00 +00:00  2026-10-27 13:00 +00:00
1            2026-10-27 13:00 +00:00  9999-12-31 00:00 +00:00

Changing the value

The value adds or removes the BG_ValidToTimestamp column in the table of every historized model object. On Microsoft SQL Server, the generated table script drops and creates the table. When you switch to true and deploy only the views and loaders, the result view fails to deploy because the table has no BG_ValidToTimestamp column yet.

Changing Persist Validity on a deployed solution changes the table of every historized object. The generated scripts do not migrate existing tables or fill BG_ValidToTimestamp for rows already loaded. Plan the table change and the backfill before you deploy, or reload the affected tables.

Release differences

  • Generator 2.2: Persist Validity is introduced.
  • Generator 2.4: Link Satellites on a Driving Key Link close the previous version per driving key.
  • Generator 2.4: a new set of a Multi-Active Satellite closes the previous set as a whole.

Details are in the Generators Release - 2.4.0 notes.

Related articles