Dynamic Data Sources

Use Case

In some scenario, you want to point the dashboards to different data source (database or data warehouse) dynamically, based on who's viewing the report or whether it's in production or dev mode.

Thanks to its programmable nature, Holistics can support this capability natively. This will enable popular use cases such as:

• Clients Dashboarding: Build the same set of models/datasets/dashboards for clients but different data source for each client underneath.
• Dev/Prod environment: Dynamically switch the underlying data sources (from dev → prod and vice versa) based on the environment that analysts are working on
• Dynamic data sources for embedded analytics: Embedded analytics but different customers use different databases.

Approach

In Holistics, you can specify a function/expression in the data source definition (of dataset or data model).

// In a dataset
Dataset sales {
  models: [ orders ]
  data_source_name: function_or_expression_here
}

// Or in a data model
Model orders {
  data_source_name: function_or_expression_here

  dimension order_id { ... }
  dimension user_id { ... }
  ...
}

The below example use an "if expression" to tell Holistics to use different database when doing development vs when being published.

Dataset sales {
  label: 'Dynamic Client Dataset'
  models: [ ... ]
  relationships: [ ... ]
  
  data_source_name:
    if (H.git.is_production) {
      'production_data_source'
    } else if (H.git.current_branch == 'staging') {
      'staging_data_source'
    } else {
      'development_data_source'
    }
}

Some notes

• Ensure data sources connected: You need to make sure you have defined the 3 data sources named production_data_source, staging_data_source, and development_data_source.

  

• Run-time evaluation: The expression is evaluated at run-time (i.e when dashboard is viewed, or queries are generated to send to database.

• data_source_name is only available when defining data model or dataset, not dashboard. The dataset's data source will override whatever defined in data model.

• It is recommended to create a separate file named database.aml to store your dynamic data sources' logic, rather than defining it directly within your dataset or model file.

  // database.aml file
  const dynamic_db = if (H.git.is_production) {
                     'production_data_source'
                   } else if (H.git.current_branch == 'staging') {
                     'staging_data_source'
                   } else {
                     'development_data_source'
                   }

  // your model file
  Model users {
      data_source_name: dynamic_db
  }
  
  // your dataset file
  Dataset ecommerce {
      data_source_name: dynamic_db
  }

Available Variables

While not exhaustive, here are some common system variables you can use:

User Attributes

You can use H.current_user.<attribute_name> to access any custom user attribute of the current user. For example, H.current_user.data_source will return the data_source user attribute value, which you can use to dynamically switch the database connection based on who's viewing the dashboard.

Note that you need to define your user attributes first in User Attributes Management before you can use them in your AML code.

In this example, each user has a data_source attribute set to their respective database name. The dataset will automatically connect to the correct database based on who's viewing the dashboard:

Dataset sales {
  data_source_name: H.current_user.data_source
  models: [ orders ]
}

System User Attributes

System User Attributes are provided by Holistics, prefixed with h_, and cannot be modified by any users.

Attribute	Description
H.current_user.h_email	The email of the current user account.
H.current_user.h_role	The role of the current user account (e.g., admin, analyst, explorer, viewer).

In this example, admins connect to the production database while other roles are routed to a restricted data source:

Dataset sales {
  data_source_name:
    if (H.current_user.h_role == 'admin') {
      'production_data_source'
    } else {
      'restricted_data_source'
    }
  models: [ orders ]
}

Holistics built-in variables

These are environment variables that help you set up dynamic data sources easily based on branch or dev/prod environment.

Variable	Description
H.git.current_branch	Returns the name of the current Git branch.
H.git.is_production	Returns true when in the Reporting tab or in the Development workspace with production mode enabled.

For example, this is a sample setup that:

• In Production: use the data_source user attribute value of the current user
• In Development: use the data source develop

Dataset sales {
  data_source_name:
    if (H.git.is_production) {
      H.current_user.data_source
    } else {
      'development_data_source'
    }
}

Example: Dynamic Data Source at User Level

Suppose you have many different customers who want the same set of reports. You maintain different data source for each customer. You want each customer when logging in to Holistics will be able to see the same reports but pointing to their respective database.

Here's how you can utilize user attributes in Holistics to achieve that.

1. Connect databases

First, connect to all of your customers' databases.

2. Define new user attribute & set values for each user

Go to Users (or Group Management) in Holistics, define a new attribute named data_source (or any name you prefer — the attribute name just needs to match what you reference in your AML code). You can do this either at the user level or user group level.

Once done, to go each user and set the corresponding data_source value for them. For more information, refer to User Attributes

3. Write dynamic code to set data source

Dataset dynamic_client_dataset {
	label: 'Dynamic Client Dataset'
	
	// The underlying data source will be dynamically switched based on who use it 
    data_source_name: H.current_user.data_source
	
	models: [ revenue ]
	relationships: [ ]
}

4. Making sure that it works as expected

To make sure your setup work correctly, go to "Organization Settings > View and Edit as" under App Settings to test with each account. For more details, please refer to Log In As Another User

By selecting a particular user or user group, the corresponding value of their user attribute (in this case, the data source name) will be applied to the data_source_name property of the dataset (and model). This allows the same dashboards to display different data for different users.

Important note

Please be aware that testing this setup in the Development environment is not possible, particularly for users without access to the Modeling layer (such as Explorers or Viewers).

Therefore, you must first publish your changes to the Production environment before utilizing the "View and Edit as" option.