LookML support

Count supports importing and on-the-fly conversion of LookML files into Count catalog views and datasets. This allows teams migrating from Looker, or maintaining a LookML-based semantic layer alongside Count, to reuse their existing LookML definitions. Not all LookML features are supported. See Limitations for details.

Overview

LookML support works in two modes:

  1. Automatic conversion - LookML files in the catalog repo are converted on-the-fly into Count views and datasets.
  2. Manual conversion - A one-time import that produces first-party Count YAML files from LookML, either by uploading a LookML project or converting existing .lkml files already in the repo.

Additionally, Count catalog files can extend LookML files (or other Count files), inheriting their fields and properties while allowing overrides and omissions.

Automatic Conversion

When LookML files (.view.lkml, .model.lkml, .explore.lkml) are present in a catalog repo, either uploaded directly or included from a connected GitHub repository, they can be automatically converted into Count views and datasets. Whenever these files change, the generated Count files are automatically updated to reflect the latest LookML definitions. This allows teams to maintain their LookML files as the source of truth while using Count for exploration and modeling.

Automatic conversion is controlled via the count_catalog.yml config file:

Loading code...

How It Works

  • LookML .view.lkml files are converted to Count views (.view.yml).
  • LookML .model.lkml and .explore.lkml files are converted to Count datasets (.dataset.yml).
  • Converted files are generated on the fly and appear in the catalog editor as read-only generated files, tagged with their source.
  • If a first-party Count file exists with the same name as a generated file, the first-party file takes priority and the generated file is marked as "Overridden".
  • LookML view refinements (views whose names start with "+") are merged with their base view automatically.

Include/Exclude Patterns

The include and exclude arrays accept glob patterns matched against file paths in the repo:

  • If `include` is specified, only files matching at least one include pattern are converted.
  • If `exclude` is specified, files matching any exclude pattern are skipped, even if they match an include pattern.
  • If neither is specified, all LookML files are converted.

Manual Conversion

Manual conversion produces first-party Count YAML files from LookML. Unlike automatic conversion, the resulting files are regular catalog files that you own and can edit freely. It should be noted that manual conversion (unlike automatic conversion) does not keep the Count files in sync: if the original LookML files change, the manually converted Count files will not update automatically. This approach is best for teams who want to migrate their LookML definitions into Count and then maintain them directly in Count going forward.

Import LookML Project

Upload a LookML project (a set of .lkml files) through the catalog editor's "Import LookML project" action. This parses the uploaded files, converts them, and presents a selection UI where you can choose which views and datasets to create.

Convert Existing Files

If LookML files are already present in the repo (e.g. from a connected GitHub repository), use the "Convert LookML files" action in the catalog editor to convert them into first-party Count files. A modal allows you to review and select which files to convert.

When files are manually converted, automatic conversion is disabled for those files to prevent duplicates (it can however be re-enabled if needed by editing the count_catalog.yml configuration).

Extending Files

Count catalog files can extend other files using the extends property. Files that can be extended include both LookML files and Count YAML files. See here for more information about extending Count YAML files.

Extending LookML files allows you to reuse and customize LookML definitions without modifying the original LookML files. While LookML views without a data source (i.e. no sql_table_name or derived_table) can't be converted as they are, they can still be extended in this way.

Extending a View

Loading code...

Extending a Dataset

Loading code...

LookML Conversion Details

What Is Converted

  • LookML view with sql_table_name -> Count view with table source
  • LookML view with derived_table.sql -> Count view with query source
  • LookML dimension -> Count field (no aggregate)
  • LookML dimension group (type: time) -> Count field with timeframes
  • LookML measure -> Field with aggregate
  • LookML explore -> Count dataset
  • LookML view refinements (+view_name) -> Merged with base view
  • LookML view extends -> Separate view extending base view
  • LookML case blocks -> SQL CASE WHEN expressions in fields
  • LookML tier/bin types -> SQL CASE WHEN expressions in fields
  • LookML measure with filters -> Aggregate `CASE WHEN` expressions
  • LookML manifest constants (@{name}) -> Resolved inline
  • LookML ${TABLE}.column references -> Resolved to column
  • LookML ${field_name} references -> Resolved to field expressions

Supported Types

string, number, integer, boolean, yesno (converted to boolean), date, time (converted to date).

Supported Aggregation Types

count, count_distinct, sum, sum_distinct (converted to sum), avg, average (converted to avg), average_distinct (converted to avg), median, mode, max, min, stddev_pop, stddev_samp, var_pop, var_samp.

Supported Timeframes

raw, date, year, quarter, quarter_of_year, month, month_num, month_name, week, day_of_year, day_of_month, day_of_week, hour, minute, second, and their _trunc variants.

SQL Rewrites

The converter applies several SQL transformations to ensure compatibility:

  • CURRENT_DATE() / CURRENT_TIMESTAMP() → today() / now()
  • DATE_DIFF(...) / DATEDIFF(...) (BigQuery and Snowflake variants) → date_sub(...)
  • CAST(... AS INT64) → CAST(... AS INTEGER)

Format Conversion

Common LookML value formats are mapped to Count format specifications, including currency formats (usd, gbp, eur, etc.), percentage formats, and decimal precision formats.

Limitations

Count supports a broad subset of LookML. However, certain LookML features do not have direct equivalents in Count. During conversion:

  • Unsupported views, datasets, or fields are skipped.
  • The skipped definitions are included as commented sections in the generated files.
  • An explanation is provided inline to indicate why the conversion was not possible.

This ensures that no definitions are silently dropped and that any required manual adjustments are visible.

Below are the current known limitations when converting LookML to Count.

Parameters and Liquid Templating

LookML parameter definitions (`parameter`) and Liquid template expressions ({% ... %}, {{ _filters['...'] }}) are not supported. Fields that rely on parameters or Liquid templating will be commented out in the converted output with an explanation.

Cross-View Field References

Referencing fields from other views in field expressions (e.g. ${other_view.field_name}) is not supported. Only references to fields within the same view (${field_name}) and the table reference (${TABLE}.column) are resolved.

Drill Fields and Sets

LookML set definitions and drill_fields are not converted. These are skipped during conversion as Count does not have an equivalent concept.

Field Expression SQL

Field expressions can only use a limited SQL dialect that Count uses in various places such as visuals and low-code cells (see here). Complex SQL constructs, warehouse-specific functions, or deeply nested subqueries may not convert successfully. Fields with unsupported expressions are commented out with a note explaining the issue.

Views Without Data Sources

LookML views that have no sql_table_name or derived_table (i.e. views intended to be used only via extends) produce views without a source. These views cannot be used directly in Count but can be extended by Count catalog files that provide their own source.

Other Unsupported LookML Features

  • Relative date filters (sql_always_where with Liquid date filters)
  • User attribute references (_user_attributes)
  • html property on fields
  • link property on fields
  • order_by_field
  • Custom value_format strings (common named formats are supported)
  • Some join types may not have direct equivalents