Migrating Looker Models to Holistics

High-level Overview

In Looker, a model is a collection of explores that share common configurations like connection, access grants, and datagroups. However, there is no direct equivalent concept in Holistics.

Instead, in Holistics:

• Each explore is converted to a separate dataset
• Each dataset is defined in its own file for better organization and management
• Common configurations are handled differently:
  • Connections are defined per dataset
  • Access control is managed through Holistics' permission system
  • Data refresh is handled through persistence and schedules

For example, this Looker model:

// in model.lkml
connection: "warehouse"
include: "views/*.view"

explore: orders {
  join: users { ... }
}

explore: products {
  join: categories { ... }
}

Would be converted to separate dataset files in Holistics:

// in datasets/orders.dataset.aml
Dataset orders {
  data_source_name: 'warehouse'
  // ... dataset configuration
}

// in datasets/products.dataset.aml
Dataset products {
  data_source_name: 'warehouse'
  // ... dataset configuration
}

Step-by-Step Migration Tutorial

Step 1: Plan Dataset Structure

1. Identify all explores in your Looker model
2. Plan how to organize them into separate dataset files
3. Note any shared configurations that need to be handled

Step 2: Create Datasets

1. Organize your datasets into separate files:

📁 datasets/
  📄 orders.dataset.aml
  📄 products.dataset.aml
  📄 users.dataset.aml

2. For each explore in your Looker model, create a corresponding dataset following the Explore Migration Guide.

Step 3: Handle Common Configurations

1. Connection: Set in each dataset

// Looker
connection: "warehouse"

// Holistics - set in each dataset
Dataset orders {
  data_source_name: 'warehouse'
}

2. Access Control: Unlike Looker's access_grants in model files, Holistics provides several permission options that are configured through the UI:

   • Resource Access Control: Control access at Dataset and Dashboard levels
   • Row-level Permission: Filter data based on user attributes. See Row-level Permission
   • Column-level Permission: Restrict access to specific columns. See Column-level Permission

   For a complete overview of Holistics' permission system, see our Permission System documentation.

Step 4: Test and Validate

1. Verify all datasets are working correctly
2. Check access controls are properly implemented
3. Test query performance
4. Compare results with original Looker model

Detailed Feature Comparison

LookML Parameter	Purpose	Support	Holistics Equivalent & Implementation
Structural Parameters
access_grants	Creates an access grant that limits access of LookML structures to only those users who are assigned an approved user attribute value. This parameter has the user_attribute and allowed_values subparameters. Once defined, you can use the required_access_grants parameter at the Explore, join, view, or field level to require the access grant to access those structures.	✔️ (partially)	Holistics supports several permission options - Resource Access Control (Dataset and Dashboard) - Role-level Perrmission - Column level permission
explore	Define the Explore	✅	Holistics Dataset is the equivalent of Looker Explore. To migrate Explore, you can use the Explore Migration Guide.
include	Adds files to a model	❌	Holistics does not require this parameter.
test	Creates a data test to verify your model's logic. This parameter has the explore_source and assert subparameters.	❌	Holistics does not support data test yet.
Display Parameters
label (for model)	Changes the way a model appears in the Explore menu	❌
Filter Parameters
case_sensitive (for model)	Specifies whether filters are case-sensitive for a model	✅	Users can control this with AQL operator
Query Parameters
connection	Changes the database connection for a model	✅	using data_source_name property in Dataset as data_source_name: 'source_name'
datagroup	Creates a datagroup-caching policy for a model. This parameter has the label, description, max_cache_age, and sql_trigger subparameters.	❌	Not suppported yet.
fiscal_month_offset	Specifies the month your fiscal year begins (if it differs from the calendar year)	❌	Not support yet
persist_for (for model)	Changes the cache settings for a model	❌	Not support yet
persist_with (for model)	Specifies the datagroup to use for the model's caching policy	❌	Not support yet
week_start_day	Specifies the day of the week on which week-related dimensions should start	✅	Holistics Week Start Day
Visualization and Formatting Parameters
map_layer (for model)	Creates custom maps to be used with map_layer_name	✅	Holistics Custom Map
named_value_format	Creates a custom value format to be used with value_format_name. This parameter has the value_format and strict_value_format subparameters.	❌	Not supported yet.