Dimensions (Looker to Holistics)

High-level Overview

Looker dimensions and Holistics dimensions serve similar purposes but have some key differences in syntax and capabilities:

1. Syntax Differences

   • Looker uses ${TABLE} for table references, Holistics uses #SOURCE
   • Looker uses ${field_name} for field references, Holistics uses {{ field_name }}
   • Looker uses sql: for definitions, Holistics uses definition: @sql or definition: @aql

2. Data Types

   • Looker: string, number, time, yesno
   • Holistics: text, number, datetime/date, truefalse

3. Date Handling

   • Looker uses dimension_group to create multiple time-based dimensions at modeling time
   • Holistics provides flexible date handling at query time - users can change date grains and extract date parts directly in the UI without requiring predefined dimensions. Please visit Date Drill, Date Part, and Time Intelligence Functions for more details.

Step-by-Step Migration Tutorial

Step 1: Set Up Your Environment

1. Open your Looker view file containing the dimensions
2. Create a new Holistics model file
3. Have the type mapping reference ready

Step 2: Migrate Basic Dimensions

1. Start with simple column references:

// Looker
dimension: first_name {
  label: "First Name"
  type: string
  sql: ${TABLE}.first_name ;;
}

// Holistics
dimension first_name {
  label: 'First Name'
  type: 'text'
  definition: @sql {{ #SOURCE.first_name }};;
}

Step 3: Handle Computed Dimensions

1. Convert SQL references:

// Looker
dimension: full_name {
  type: string
  sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}

// Holistics
dimension full_name {
  type: 'text'
  definition: @sql CONCAT({{ first_name }}, ' ', {{ last_name }});;
}

Step 4: Migrate Case Statements

1. Convert Looker's case syntax to SQL CASE:

// Looker
dimension: size_tier {
  case: {
    when: {
      sql: ${size} < 10 ;;
      label: "Small"
    }
    when: {
      sql: ${size} >= 10 AND ${size} < 50 ;;
      label: "Medium" 
    }
    else: "Large"
  }
}

// Holistics
dimension size_tier {
  type: 'text'
  definition: @sql 
    CASE 
      WHEN {{ size }} < 10 THEN 'Small'
      WHEN {{ size }} >= 10 AND {{ size }} < 50 THEN 'Medium'
      ELSE 'Large'
    END;;
}

Step 5: Handle Date Dimensions

1. For date/time fields, you only need to define the base datetime dimension:

// Looker
dimension_group: created {
  type: time
  timeframes: [date, week, month, year]
  sql: ${TABLE}.created_at ;;
}

// Holistics
dimension created_at {
  type: 'datetime'
  definition: @sql {{ #SOURCE.created_at }};;
}

In Holistics, users can change date grains (year, quarter, month, week, date) and extract date parts directly in the UI without requiring predefined dimensions like in Looker. Please refer to:

• Date Drill
• Date Part
• Time Intelligence Functions

Step 6: Test and Validate

1. Check all dimension types are correctly mapped
2. Verify SQL references are properly converted
3. Test each dimension in a simple report
4. Compare results with original Looker dimensions

Reference Manual

Type Mapping

Looker Type	Holistics Type	Notes
string	text	Direct mapping
number	number	Direct mapping
time	datetime	Use date for date-only values
yesno	truefalse	Direct mapping
tier	text	Convert to CASE statement
location	text	No direct equivalent

Property Mapping

Looker Property	Holistics Property	Notes
label	label	Direct mapping
description	description	Direct mapping
hidden	hidden	Use true/false instead of yes/no
sql	definition	Must include @sql or @aql tag
type	type	See Type Mapping

Unsupported Features

The following Looker features don't have direct equivalents in Holistics:

• alpha_sort
• order_by_field
• suggest_dimension
• suggest_explore
• tags
• drill_fields -> will be supported in the future (learn more)

Common Patterns

1. SQL References

   • ${TABLE} → {{ #SOURCE }}
   • ${dimension_name} → {{ dimension_name }}
   • ${created_date} → {{ created_date }}

2. Boolean Logic

   // Looker
   type: yesno
   sql: ${value} > 100 ;;
   
   // Holistics
   type: 'truefalse'
   definition: @sql {{ value }} > 100;;

3. String Concatenation

   // Looker
   sql: ${first_name} || ' ' || ${last_name} ;;
   
   // Holistics
   definition: @sql {{ first_name }} || ' ' || {{ last_name }};;
   // or
   definition: @aql concat(users.first_name, ' ', users.last_name);;

Best Practices

1. Use AQL for Complex Transformations

   • AQL provides better readability and maintainability
   • Easier to handle complex business logic
   • Better error messages and type checking

2. Consistent Naming

   • Keep dimension names consistent with Looker for easier maintenance
   • Use clear, descriptive names for new dimensions

3. Documentation

   • Always include descriptions for dimensions
   • Document any deviations from Looker implementation

4. Testing

   • Create test reports to validate migrated dimensions
   • Compare results with original Looker reports
   • Test edge cases and null handling

Detailed Feature Comparison

LookML Parameter	Purpose	Support	Holistics Equivalent & Implementation
Structural Parameters
dimension	Creates a dimension field	✅	Holistics dimension
dimension_group	Creates several time-based dimensions at the same time	✅	Holistics has several equivalent options: - Date Drill - Date Part - Time Intelligence Functions
Action and Linking Parameters
action	Creates clickable actions on dimension values	✔️ (partial)	Holistics Actions Note: Holistics Actions can only be defined in Dashboard layer
drill_fields	Specifies fields to show when drilling into dimension	🛠️ (will support soon)	Holistics Drill Down
tags	Adds text that can be passed to other applications	❌	No direct equivalent
link	Creates links to other Looker content or external URLs	✅	Can be solved with Holistics Actions
Display Parameters
alias	Creates alternate names for backward compatibility	❌	No direct equivalent
alpha_sort	Makes case parameter sort conditions alphabetically	❌	No direct equivalent
description	Adds explanatory text for the dimension	✅	Uses description parameter
group_label	Groups dimensions together under a heading	❌	No direct equivalent
group_item_label	Specifies label for field under its group label	❌	No direct equivalent
hidden	Controls visibility in the UI	✅	Uses hidden parameter with true/false
label	Changes how the dimension appears in the UI	✅	Uses label parameter
order_by_field	Sorts dimension by values of another field	❌	No direct equivalent
style	Changes how tiers appear in UI	❌	No direct equivalent
view_label	Changes how dimension's view appears in field picker	❌	No direct equivalent
Filter Parameters
can_filter	Lets you prohibit a dimension from being used as a filter	❌	No direct equivalent
case_sensitive	Controls case sensitivity in filters	❌	No direct equivalent
skip_drill_filter	Stops dimension from being added to filters when drilling	❌	No direct equivalent
Filter Suggestion Parameters
bypass_suggest_restrictions	Shows suggestions when sql_always_where is in use	❌	No direct equivalent
full_suggestions	Controls how database is queried for suggestions	❌	No direct equivalent
suggest_dimension	Bases suggestions on values of different dimension	❌	No direct equivalent
suggest_explore	Bases suggestions on values of different explore	❌	No direct equivalent
suggest_persist_for	Changes cache settings for suggestions	❌	No direct equivalent
suggestable	Enables or disables suggestions for a field	❌	No direct equivalent
suggestions	Controls filter suggestions	❌	No direct equivalent
Query Parameters
convert_tz	Controls timezone conversion	❌	No direct equivalent
primary_key	Indicates if the dimension is a primary key	❌	No direct equivalent
required_access_grants	Controls access based on user attributes	❌	No direct equivalent in basic AMQL, but Holistics handles access control differently
required_fields	Requires additional fields when this field is chosen	❌	No direct equivalent
Value and Formatting Parameters
html	Modifies HTML output using Liquid templating	❌	No direct equivalent
sql	Defines the SQL expression for the dimension	✅	Uses definition with either @sql or @aql tag
sql_latitude	Defines latitude for location type dimensions	❌	No direct equivalent
sql_longitude	Defines longitude for location type dimensions	❌	No direct equivalent
type	Specifies the data type of the dimension	✅	Uses type with values: 'text', 'number', 'date', 'datetime', 'truefalse'
Visualization Parameters
map_layer_name	Specifies custom map for geographic data	❌	No direct equivalent

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