Overview

LookML is the language Looker uses to describe dimensions, aggregates, calculations, and data relationships in a SQL database, and to construct SQL queries against that database. For recommended steps to learning LookML, see the Steps to learning LookML documentation page.

You can use this reference page to identify how LookML parameters can help you achieve the data modeling effects you want. This reference may also be useful if you are looking at an existing model and want to know what each parameter is doing. You may also want to visit the individual reference pages for the relevant LookML structures: model, view, Explore, join, manifest, or fields.

For an introduction to these LookML structures and how they relate to each other, see the LookML terms and concepts documentation page. You can find links to additional resources at the bottom of this page to help you identify, understand, and implement LookML elements.

How to read this reference

On this page, parameters are organized by the different functions they can accomplish and the different effects you can achieve with them.

The table entry in each section lists:

Some field-level parameters can be used with multiple field types, so on this page we mark each field-level parameter with icons indicating the field types it can be used with. You can hover over an icon to see its name, or click it to see a reference page for that field type.

Structural parameters

These LookML parameters affect the structure of a project or its underlying files.

Major structural parameters in a model or an Explore file

As shown on the LookML terms and concepts documentation page, a project contains one or more model files, which use parameters to define a model and its Explores and joins.

This section describes the major structural parameters that you typically put in a model file. These act as the framework for all other parameters. An explore parameter is usually defined at the top level of a model file, but when you are using a native derived table it may be defined in an Explore file.

Major structural parameters in a view file

As shown on the LookML terms and concepts documentation page, a project contains one or more view files, which use parameters to define that view, its fields (including dimensions and measures), and its sets of fields.

This section describes the major structural parameters that you typically put in a view file.

Helper structural parameters

These parameters help you define the structural behavior you want, such as letting you specify sets of fields, include certain files (and their contents), reuse definitions, and so on.

Extension framework applications

Looker developers can add an application to Looker’s extension framework using the application parameter in a project’s manifest file. Once an extension is added to a project, Looker users with appropriate permissions can see the extension listed in the Looker Browse menu.

If your admin has enabled the Enhanced Navigation Labs feature, extensions are listed in the Applications section of the new enhanced left navigation panel.

Explore name and menu

The name of an Explore and its appearance on the Explore menu can help your users choose the right Explore for their needs. These LookML parameters affect the default behavior for an Explore’s name and appearance on the Explore menu.

For further discussion, see the Explore name and menu section of the Changing the Explore menu and field picker documentation page.

Default behavior

The default behavior for an Explore’s name and its appearance on the Explore menu is specified by the parameters listed below.

Modifying the Explore name and menu

The Explore name and how it appears on the Explore menu can be modified by the parameters in the table below.

Field picker

The organization and display names of the views and fields in the field picker can help users understand visualizations and find the fields they need in Explores. These LookML parameters affect the default behavior for the field picker’s contents, appearance, and organization.

For further discussion, see the Field picker section of the Changing the Explore menu and field picker documentation page.

Default behavior

The default field picker appearance and behavior is specified by the parameters listed below. For a full explanation of this default behavior, see the Field picker display section of the Changing the Explore menu and field picker documentation page.

Modifying the view names in the field picker

A view’s display name can help your users understand and find the fields they need in Explores. If a visualization shows the view name, then modifying the way the name appears can help users understand the visualization. This section describes the LookML parameters that affect the view names in the field picker. For a full explanation of this topic, see the Field picker section of the Changing the Explore menu and field picker documentation page.

Modifying the field listings in the field picker

Modifying the way that fields are listed can help your users understand visualizations and find the fields they need in Explores. The way fields are listed in the field picker can be modified by the parameters in the table below. For a full explanation of this topic, see the Field picker section of the Changing the Explore menu and field picker documentation page.

Modifying the organization of fields in the field picker

The organization of fields can help your users find the fields they need in Explores. The organization of fields in the field picker can be modified by the parameters in the table below. For a full explanation of this topic, see the Field picker section of the Changing the Explore menu and field picker documentation page.

Localization

If you are localizing your model, the location settings parameters let you customize the display of the labels and descriptions in the Looker UI based on the user’s locale setting. See the Model localization documentation page for information on setting up your model for localization.

Data values and data display

Modifying the values and presentation of the data in the Data section of an Explore can help your users understand their results. You may want to modify or restrict the types of data for your dimensions or measures, change the format of the data your users see, fill in missing values, or change other visualization options.

Users can also define their own table calculations that show in the Data section. However, when possible, you should define dimensions and measures in LookML so that the correct calculation is made once and then used consistently in various queries.

Data values for multiple field types

These parameters let you change data values for multiple field types.

Data values for specific dimension types

You can modify the data values for some types of dimensions using type-specific parameters.

Dimensions of type: date or type: datetime

Dimensions of type: distance

Dimensions of type: location

Dimensions of type: string

Dimensions of type: tier

Dimension groups of type: duration or dimensions of type: duration_x

Data values for measures

Most of these parameters are limited to specific measure types, as specified in the table. To create a count filtered by a dimensional value, see Filtering counts by a dimension. To create a measure that calculates the percentage between two fields, see Percentages.

Data formats

You can make data values more easily readable for your users by formatting the data using the parameters in the following table.

Data order and filling

For most fields, the sort order is straightforward — just an alphanumeric sort of the values. In some cases, you may want the results of a New LookML case or Old LookML sql_case statement to sort in a particular order. Or you may want the values to sort by another field’s value. You can also use the allow_fill parameter to enable or prevent users from asking Looker to fill in missing dates and values for a field.

Visualizing location data

Looker provides a variety of maps you can make available to visualize locational data values in the Visualization section. You can also create and use custom maps for the visualizations.

Clickable actions for data values

Drilling

In Looker, every query result can be the starting point for another query. Users can click on a data value to drill into the data. You can also use LookML to specify which fields are displayed when the user drills into the data. Dimensions and measures have different default behavior for drilling.

For advanced options for building out a custom drill path, see the More powerful data drilling article in the Help Center.

Data actions

Sometimes your users will want to be able to trigger other events after viewing the data. If you are using the Looker Action Hub, you can specify that fields with certain tags can use specific integrated services. You can also use data actions to specify what options are available to the users for a field.

Linking

You can let your users click on a data value to navigate to a related URL. With these parameters, you can specify which fields are displayed when the user drills into the data, as well as the text to display, the destination URL, and a favicon for the destination website.

Filtering

Users can apply filters to their queries in Explores, Looks, and dashboards.

You can help curate the user’s experience by specifying filter behavior directly in your LookML, like adding helpful filters or ensuring that they don’t accidentally create a query that puts too much demand on your database resources. You can specify filter behaviors like case-sensitivity, default values, and the filter suggestions that Looker can generate while the user is typing.

For more general discussion of filtering in LookML, see Filtering result sets on the Additional LookML basics documentation page. For advanced options using templated filters, see the Templated filters and Liquid parameters and Advanced templated filters articles in the Help Center.

You can find a full list of filter expressions and syntax on the Looker filter expressions documentation page.

Requiring filters with fixed values

These parameters let you specify filters that will always be applied.

See also Filtering counts by a dimension on the Additional LookML basics documentation page.

Requiring filters with changeable values

These parameters let you specify filters that must be used, but permit the user to change the filters’ values.

Preventing filters

These parameters let you prevent a user from using a field as a filter, either in all circumstances or just when drilling.

Conditional filters

In some cases, you may want to specify that the user must use one of several filters to narrow their query. For example, the user must limit the query by date or by region.

In addition to the parameter below, see also Filtering result sets on the Additional LookML basics documentation page.

Filter value behavior

To make filtering easier for your users, you can provide a default value for the filter or treat the filter values as case-insensitive.

Filter suggestions

Filter suggestions are a great way to help your users filter data successfully. In some cases, it may be useful to disable suggestions or to change the suggestion behavior.

These LookML parameters affect the default behavior for filter suggestions.

Default behavior

By default, Looker’s suggestions for a given filter field are based on all the unique values in that field’s data.

Enabling or disabling suggestions

If you think that a field has a very large number of unique values, it might make sense to disable filter suggestions for that field. That prevents the user from having to wade through too many suggestions and the database from having to provide those suggestions. You can enable or disable filter suggestions at several levels.

Suggestion values

By default, Looker generates filter suggestions based on a field’s unique values. In some cases, the suggestions might be more useful if you specified the values Looker should suggest, like the most likely values. Additionally, if you are limiting access to some values in the data, then you can choose to apply or not apply those limits to the suggestions.

Caching suggestions

By default, Looker generates filter suggestions based on a field’s unique values. Those values are cached to help performance, but you can change the length of time that the cached values are used. If the data is fairly stable, consider using a longer time to improve the performance for getting those suggestion values.

Joining views

As discussed in Working with joins in LookML, joins enable the exploration of data from more than one view at the same time. You can join together different views to let users see how parts of your data relate to each other.

Joins are defined in the model file to establish the relationship between an Explore and a view. Joins connect one or more views in a single Explore, either directly or through another joined view.

These LookML parameters let you create joins and specify how they work.

What to join

There are a variety of parameters that specify what views to join, in general and specific situations. In addition, you can specify which fields will be brought into the join.

How to join

You can specify how the joins between views should work and what the join condition will be. You should also specify a primary key so that Looker can use symmetric aggregates to provide correct results for aggregate functions.

For further discussion of symmetric aggregates, see also the A simple explanation of symmetric aggregates, or “Why on Earth does my SQL look like that?” and The problem of SQL fanouts Help Center articles.

Caching

Looker reduces the load on your database and improves performance by using cached results of prior queries when available and permitted by your caching policy. In addition, you can create complex queries as persistent derived tables (PDTs), which store their results to simplify later queries. When planning your caching, you should consider both performance and how “fresh” the data should be for your users.

Caching queries

You can use datagroups to integrate Looker more closely with the ETL (extract, transform, load) phase of your data pipeline. For example, if you batch-load data through a nightly ETL job, then you can have Looker notice that the ETL has finished and clear any related cached queries.

For further discussion, see the Caching queries and rebuilding PDTs with datagroups documentation page.

Caching filter suggestions

By default, Looker generates filter suggestions based on a field’s unique values. Those values are cached to help performance, but you can change the length of time that the cached values are used. If the data is fairly stable, consider using a longer cache time to improve the performance for getting those suggestion values.

Caching for persistent derived tables

See Regeneration and caching parameters for persistent derived tables below for parameters that affect caching for persistent derived tables.

Derived tables

As discussed in the Derived tables in Looker tutorial, derived tables are important tools in Looker. They enable you to create new tables that don’t already exist in your database, expand the sophistication of your analyses, and enhance query performance.

For additional discussion, see Derived tables and facts tables and Persistent derived tables on the LookML terms and concepts documentation page.

Structural parameters for all derived tables

Derived tables can be defined using SQL or LookML. All derived tables start with this parameter:

Structural parameters for native derived tables

Native derived tables are much easier to read, understand, and reason about as you model your data.

The parameters in the table below are used to define the source data for a native derived table. They are described in further detail and shown in example usage on the explore_source parameter documentation page.

Structural parameters for SQL derived tables

For SQL derived tables, use the parameter listed below.

Structural parameters for custom data definition

For database dialects that require a custom Data Definition Language (DDL), use the parameters listed below. For example, if your database dialect doesn’t support CREATE TABLE as SELECT issued as a single SQL statement, use the create_process parameter to build a PDT in multiple steps:

Regeneration and caching parameters for persistent derived tables

As discussed in the Caching section above, you can use datagroups to manage your caching and balance efficiency with data freshness.

You can use datagroups to regenerate persistent derived tables (PDTs) when fresh data becomes available. Alternatively, you can specify that PDTs should be regenerated infrequently, even though the underlying tables update frequently, so queries against the PDTs can be cached longer.

For further discussion, see Persistence strategies on the Derived tables in Looker documentation page and the Caching queries and rebuilding PDTs with datagroups documentation page.

Query efficiency parameters for derived tables

Depending on your database dialect, there are some parameters you can use to improve the efficiency of your derived table.

Aggregate tables

As discussed on the Aggregate awareness documentation page, aggregate tables can help you optimize queries on your Explores. Aggregate tables are persisted on your database, similar to persistent derived tables (PDTs).

Aggregate tables are defined under an Explore.

Additional query behavior parameters

There are various parameters that affect what and how you query, some of which have been described in other sections of this page according to what they do. This section describes the remaining LookML parameters that let you establish query behavior.

What to query

These parameters define specific information about the connections, files, and fields that will be used for your queries.

How to query

These parameters affect how Looker constructs or handles your queries.

Several of these parameters are involved in making sure that symmetric aggregates will work. For further discussion of symmetric aggregates, see also the A simple explanation of symmetric aggregates, or “Why on Earth does my SQL look like that?” article in the Help Center.

Parameters to avoid

You may see the following parameters in your model, so we have included a list here of what they do. However, if you are adding new modeling, please avoid these parameters.

Other tutorials and resources

These sections offer links to additional resources that may deepen your understanding of LookML and support you in other developer tasks in Looker.

Understanding the development process

The Data modeling section of Looker’s documentation menu is designed to get you started in the Develop section of Looker.

Specific pages that may be helpful to look at:

• Development Mode and Production Mode
• Accessing and editing project information
• Developer video tutorials

Understanding LookML

The Steps to learning LookML section of Looker’s documentation menu is designed to introduce you to basic LookML concepts and suggest a learning path toward proficiency in LookML.

Specific pages that may be helpful to look at:

• What is LookML?
• LookML terms and concepts
• LookML quick reference

Creating LookML dashboards

Any dashboard files in a project contain dashboard-specific LookML parameters. The current page includes only data modeling parameters, not dashboard parameters, but the Creating and Managing LookML Dashboards section of Looker’s documentation menu is designed to introduce you to working with LookML dashboards.

Specific pages that may be helpful to look at:

• Building LookML dashboards
• Dashboard parameters for parameters that affect an entire dashboard
• Dashboard element parameters for parameters that affect specific elements in a dashboard

Embedding, API, and admin options

Embedding

The following pages may be helpful for learning more about embedding Looks, Explores, and dashboards:

• Public embedding with iframe tags
• Private embedding
• SSO embedding
• Embedded JavaScript events

API

The Looker API section of Looker’s documentation menu is designed to get you started with Looker’s secure, “RESTful” application programming interface (API).

Admin options

The Getting started with admin options section of Looker’s documentation menu is designed to get you started in the Admin section of Looker.

Training on Looker Connect

Register for our LookML Developer learning journey on Looker Connect.