Ro’s Looker Code Generation System: LookML Generation for Dimension Time Groups

(article #2 in series)

For background on our Ro Looker Code Generation System, please see our intro article.


Dimension time groups are important and useful, so we wanted to make them as easy as possible to define. In our LookML-generating system, we merely specify whether to generate a “low”, “medium”, or “high” number of dimensions, rather than listing each timeframe value individually.


In Looker, you usually expose a date via dimension_group with type:
. As part of this, you specify timeframes, and Looker generates a
separate dimension for each of them.

For example, given a dimension_group like:

view: orders {
# ...
dimension_group: date_fulfilled {
group_label: "WHEN"
type: time
datatype: datetime
sql: ${TABLE}.created_at ;;
timeframes: [

Looker will create a dimension for each timeframe, and each of those dimensions will be available for use both within the LookML and in the resulting view. This is how they’re displayed in the Looker UI:

Our approach

We noticed that we have many of these dimension groups, but that in practice we only use 3 combinations of timeframes. Still, when adding a new one, we’d often have to look up the list of available timeframes¹, or find an appropriate
example to copy-paste from.

So, we decided to simplify things a bit in our LookML-generation system. We
define three levels of detail: “low”, “medium”, and “high”. Any dimension with
type: time automatically gets the “medium” timeframes, and we can opt up or down by specifying timeframes: high or timeframes: low respectively.

Why not use “high” all the time? Having dimensions that won’t be used makes it harder for analysts and other business users to find the dimensions they want, and there can be a performance cost to having too many dimensions (and associated DOM nodes) in the Looker UI.


This is a small, simple part of our LookML-generation system that saves us a
couple context switches and/or typos whenever we add a dimension time group, and works well without our larger goal of making Looker views easier to create, understand, and maintain.

[1]: Is it dow or day_of_week? month_num, month_no, or month_of_year?