User Guide Getting Started Help Center Documentation Community Training
New LookML
Old LookML
New LookML
Looker
  
English
日本語
include

Usage

include: "*.view"

Hierarchy

include

- or -

include

Default Value

None

Accepts

A string containing a file name or pattern

Definition

The include parameter specifies which LookML files are made available to a model or view file. Non-LookML file types, such as documentation files, do not need to be added to a model with the include parameter. 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 all files have extensions.

The files that you may need to add with an include parameter are:

Other files that do not need to added with an include parameter are:

Using include in a Model File

The include parameter is used in model files to specify the dashboard and view files that will be available to that model. If you want to use or reference a LookML file within a model, you must add it with the include parameter.

The easiest and most common pattern is to include all files in a model as follows (note that the .lkml and .lookml extensions are not required):

include: "*.dashboard" include: "*.view"

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" include: "funnel.view"

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

Using include in a View File

The include parameter is used in view files in two cases, and otherwise is not required or recommended.

First, if a view references another view file to complete an extension, you should use include. For example:

include: "basic_order_fields.view" view: marketing_order_fields { extends: [basic_order_fields] # The file that contains the basic_order_fields } # view should be included

Second, if a view references fields from another view file, you should use include. For example:

include: "inventory.view" view: order { dimension: profit { type: number sql: ${sale_price} - ${inventory.cost} # The file that contains the inventory } # view should be included }

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

Using include to Reference Files in Another Project

The Project Import feature is an experimental Labs feature. Experimental features are not fully developed and may be significantly changed or completely removed.

If the experimental Labs feature Project Import is enabled, the include parameter can reference files in other projects that are on the same Looker instance. Only files listed in a project manifest file can be referenced. For more information about importing files from other projects, see the Importing Files from Other Projects page.

To use include with other project files, add the other project file name to the included file name as shown below:

include: "/IMPORTED_PROJECT/imported_view_1.view" include: "/IMPORTED_PROJECT/imported_view_2.view"

Although this syntax looks like a pathname, it doesn’t imply that files for the project are laid out in any particular way. You cannot use . or .. to specify relative paths as these are not paths — this is just how files are named in an include statement.

Examples

Make all dashboard and view files available to a model:

include: "*.dashboard" include: "*.view"

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

include: "order.view" include: "user.view" include: "*.dashboard"

Make the order view file available to the new_order view for extending:

include: "order.view" view: new_order { extends: [order] }

Common Challenges

Including Everything with * Can Cause Model Conflicts

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

include: "*"

This often works fine when only one model has been created within a project. However, when multiple models are in use, the * pattern can cause several types of problems. Because * 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, and so on. It’s almost always better to explicitly include only the dashboard and view files as follows:

include: "*.dashboard" include: "*.view"

Including a File with a connection Parameter Can Cause Errors

Including a file that contains a connection parameter causes the connection defined in the primary model file to be overridden by the included file. Most of the time this is not desired and can cause errors in queries. To avoid this, ensure that included files don’t declare a connection.

Autogenerating Multiple Models Can Duplicate Entities

When autogenerating a new model from a connection, the default model file uses this pattern:

include: "*.dashboard" include: "*.view"

When only one model is autogenerated into a project the syntax above works fine. However, if more than one model is autogenerated 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" include: "inventory.dashboard"

Including a LookML Dashboard That Can’t Be Found Causes a Warning

The LookML Validator issues a warning if a file has an include parameter that includes a LookML dashboard that the IDE cannot locate. This is often caused by the presence of include: *.dashboard when there are no LookML dashboards present.

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 banana.view cherry.view

You might consider names like this:

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

Then you could reference all of these files with:

include: "*.fruit.view"

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 include only the view files that are needed.

Top