include

LookML
Version

On this Page
Docs Menu

Go to Model Parameter List

Usage

- include: '*.view.lookml'
a file name or pattern

Definition

The include parameter specifies which LookML files are made available to a model file. The use of * as a wildcard character is supported, and multiple include parameters can be used.

The files that include references are listed along the left-hand side of the Looker IDE, as shown here:

File list

Although they are hidden in the UI, please note that files have extensions, as follows:

  • DOCUMENTATION section files end with the extension .md
  • MODELS section files end with the extension .model.lookml
  • DASHBOARDS section files end with .dashboard.lookml
  • VIEWS section files end with .view.lookml

The easiest and most common pattern is to include all files in a model like this:

- include: '*.dashboard.lookml' - include: '*.view.lookml'

However, some businesses have more complex model needs, or a very large number of view files, so they choose to specify individual files like this:

- include: 'events.view.lookml' - include: 'funnel.view.lookml'

You can also use an experimental feature to include view files from other projects, as discussed below.

--> {{ /describe }} {{ /version }}

Examples

Make all dashboard and view files available to a model:

- include: '*.dashboard.lookml' - include: '*.view.lookml'

Make the order view file, user view file, and all dashboard files, available to a model:

- include: 'order.view.lookml' - include: 'user.view.lookml' - include: '*.dashboard.lookml'

Common Challenges

include Should Only Be Used in Model Files

It’s best practice to only use include parameters within model files. If you place include parameters into other types of files it is easy to unintentionally add files to a model. It is also possible that the same file will accidentally be included multiple times, leading to re-definition errors.

Including Everything With *.lookml Can Cause Model Conflicts

Some users like to include everything in a single statement, like this:

- include: '*.lookml'

This often works fine when only one model has been created within a project. However, when multiple models are in use, the *.lookml pattern can cause several types of problems. Because *.lookml matches every single file (including model files) model definitions get mixed together.

Most of the time this is not desired and causes a host of problems, such as extra or missing explores, data access problems, etc. It’s almost always better to explicitly include only the dashboard and view files as follows:

- include: '*.dashboard.lookml' - include: '*.view.lookml'

Auto Generation Of Multiple Models Can Duplicate Entities

When auto-generating a new model from a connection, the default model file uses this pattern:

- include: '*.dashboard.lookml' - include: '*.view.lookml'

When only one model is auto-generated into a project the syntax above works fine. However, if more than one model is auto-generated into a project, there can be some duplication. For example, if all dashboards are included in all models, those dashboards may appear to users more than once (once for each model). To avoid this, you can use more specific references in your models so that everything only appears once:

- include: 'overview.dashboard.lookml' - include: 'inventory.dashboard.lookml'

Things to Know

Clever View File Naming Patterns Can Be Helpful

In cases where many view files need to be managed, you can list each individual view in an include parameter. However, if you name files with a clever prefix or suffix, you may be able to reduce the number of include parameters that you need to write.

For example, instead of naming files like this:

apple.view.lookml banana.view.lookml cherry.view.lookml

You might consider names like this:

apple.fruit.view.lookml banana.fruit.view.lookml cherry.fruit.view.lookml

Then you could reference all of these files with:

- include: '*.fruit.view.lookml'

Including All View Files Can Affect Performance

Some connections are associated with databases that contain a very large number of tables. While generating a view file for each table won’t impact performance in and of itself, including all of those views in a single model can slow performance. In this situation it may be desirable to only include the view files that are needed.

Still have questions?
Go to Discourse - or - Email Support
Top