Migrating Looker Views to Holistics

Overview

A view in Looker corresponds to a model in Holistics.

A view in Looker represents a database table or a derived table. In Holistics, this is equivalent to a Table Model or Query Model. Holistics Model has the equivalent common concepts like table name, dimension, and measure.

Step-by-Step Migration Tutorial

Step 1: Identify View Type

Determine if the view is based on a table or a derived query:

• Table-based view → Table Model
• Derived view → Query Model

Step 2: Create Model Structure

For table-based views:

// Looker
view: orders {
  sql_table_name: public.orders ;;
  
  # fields defined here...
}

// Holistics
Model orders {
  type: 'table'
  data_source_name: 'warehouse'
  table_name: 'public.orders'
  
  // fields defined here...
}

For derived views:

// Looker
view: active_users {
  derived_table: {
    sql: SELECT 
      user_id,
      COUNT(DISTINCT order_id) as order_count
      FROM orders 
      WHERE status = 'completed'
      GROUP BY 1 ;;
  }
}

// Holistics
Model active_users {
  type: 'query'
  data_source_name: 'warehouse'
  query: @sql 
    SELECT 
      user_id,
      COUNT(DISTINCT order_id) as order_count
    FROM orders 
    WHERE status = 'completed'
    GROUP BY 1;;
}

Step 3: Add Data Source Name to Your Models

Unlike Looker where connections are defined at the model level, Holistics requires explicitly specifying the data source for each model. Check the connection property in your Looker model file and add it to your Holistics model:

Looker model file

connection: "warehouse"  // Defined once at model level
include: "views/*.view"

explore: order_items {
  join: products { ... }
  join: orders { ... }
}

Holistics model file

Model order_items {
  data_source_name: 'warehouse'  // Required in each model
}

For more details on connection differences, see Conceptual Differences: Data Source Connection.

Step 4: Migrate Fields

After setting up the model structure, migrate the fields following these dedicated guides:

• For dimensions, follow the migrating dimension guide
• For measures, follow the migrating measure guide

These guides provide detailed instructions for converting different types of fields and their properties.

Step 5: Handle Persistence (for derived views)

In Looker, persistence is configured within the derived table:

views/order_summary.view.lkml

view: order_summary {
  derived_table: {
    sql: SELECT 
          user_id,
          COUNT(*) as order_count,
          SUM(amount) as total_amount
        FROM orders 
        GROUP BY user_id ;;
    interval_trigger: "24 hours"
  }
}

In Holistics, we handle this with Query Model persistence and schedules: Define the persistence in the model's definition, and set up the schedule in the schedules.aml file.

models/order_summary.model.aml

Model order_summary {
  type: 'query'
  query: @sql 
    SELECT 
      user_id,
      COUNT(*) as order_count,
      SUM(amount) as total_amount
    FROM orders 
    GROUP BY user_id;;
    
  persistence: FullPersistence {
    schema: 'persisted'
    view_name: 'order_summary'
  }
}

schedules.aml

const schedules = [
  // Refresh order_summary daily at midnight
  Schedule { 
    models: [order_summary], 
    cron: '0 0 * * *'  // daily at midnight
  }
]

For more details on persistence options in Holistics, see our Persistence documentation.

Step 5: Test and Validate

1. Verify all fields are correctly migrated
2. Check data types are properly mapped
3. Test derived calculations
4. Compare query results with Looker

Step 6: Continue migrating models and explores

For more details on migrating models and explores, see the following guides:

• Model Migration Guide
• Explore Migration Guide

Reference Manual

Model Types

Looker View Type	Holistics Model Type	When to Use
Regular View	Table Model	For direct table access
Derived View	Query Model	For custom SQL queries
Extended View	Extended Model	For reusing existing models

Common Patterns

1. Extension

   // Looker
   view: extended_orders {
     extends: [orders]
     
     dimension: is_high_value {
       type: yesno
       sql: ${amount} > 1000 ;;
     }
   }
   
   // Holistics
   Model extended_orders = orders.extend({
     label: 'Extended Orders',
     dimension is_high_value {
       type: 'truefalse'
       definition: @sql {{ amount }} > 1000;;
     }
   })

   More details about extension can be found in AML Extension

Detailed Feature Comparison

LookML Parameter	Purpose	Support	Holistics Equivalent & Implementation
Structural Parameters
drill_fields	Control which fields to show when drilling/clicking a field	❌	Holistics currently supports drilling between dashboards as in Drill Through, but we haven't supported field-level control yet
extend (for view)	Build a new View based on an existing View	✅	Holistics AML Extend
extension	Force using extends on a view	🧪 (partial)	Holistics doesn't support this exact concept but we can rebuild this via Function
include	Add files to a view
test	Creates a data test to verify your model's logic.	❌	Holistics doesn't support this feature yet.
set	Defines a set of dimensions and measures to be used in other parameters	❌	Holistics doesn't support this feature yet.
view	Create a view	✅	Holistics data model
Display Parameters
label	The label of the view	✅	Holistics model's label label: 'Your Model Label'
fields_hidden_by_default	When set to yes, hides all fields in the view by default.	🧪 (partial)	Holistics doesn't support this exact concept but we can extend a Model to hide fields
Field Parameters
suggestions (for view)	Enables or disables suggestions for all dimensions on this view	❌
Query Parameters
required_access_grants (for view)	Limits access to the view to only users whose user attribute values match the access grants	❌
sql_table_name (for view)	Changes the SQL table on which a view is based	✅	- data_source_name: for specifying the data source name - table_name: for specifying the table name in TableModel - For dynamic schema, see our doc here
Derived Table Parameters
derived_table	A table based on a query	✅	Query Model
sql (for derived_table)	Declares the SQL query for a derived table	✅	Using query: @sql your_query_here ;; parameter in Query Model
explore_source	Defines a native derived table based on an Explore	❌	Holistics doesn't support this feature yet.
sql_create	Defines a SQL CREATE statement to create a PDT on a database dialect that requires custom DDL commands	✅	Custom Persistence DDL
datagroup_trigger	Specifies the datagroup to use for the PDT rebuilding policy	✔️ (partial)	Holistics doesn't have the exact concept of datagroup, but we can set schedule trigger on individual query model
interval_trigger	Specifies the interval to use for the PDT rebuilding policy	✅	Using Holistics schedule trigger defined in schedules.aml file
sql_trigger_value	Specifies the condition that causes a PDT to be regenerated	❌	Not supported yet in Holistics.
persist_for (for derived_table)	Sets the maximum age of a PDT before it is regenerated	✔️ (partial)	Users cannot control this in Holistics yet, and the default value is 24 hours
increment_key	The increment_key specifies the time increment for which fresh data should be queried and appended to the PDT.	✅	Using increment_column: 'your_column' parameter in persistence: IncrementalPersistence { }
Field Reference Parameters
dimension	list of dimensions	✅	Dimension migration guide
measure	list of measures	✅	Measure migration guide
dimension_group	Creates several time-based dimensions at the same time	✅	Holistics has several equivalent options: - Date Drill - Date Part - Time Intelligence Functions
sets	Define a set of dimensions and measures to be used in other parameters	✅	Holistics doesn't have the exact set concept, but we a wide range of reusability features such as: - Constant - Function - Extend - String Interpolation
parameter, filter for Templated filters	Creates a filter-only field that can be used to filter Explores, Looks, and dashboards but that cannot be added to a result set.	✅	Query Parameter

(*) Looker Parameters that are not mentioned in this table are generally not supported