home User Guide Getting Started Help Center Documentation Community Training Certification
menu
close
settings
Looker keyboard_arrow_down
language keyboard_arrow_down
English
Français
Deutsch
日本語
search
print
extends (for Explores)

This page refers to the extends parameter that is part of an Explore.

extends can also be used as part of a view, as described on this documentation page.

extends can also be used as part of a LookML dashboard, as described on this documentation page.

Usage

explore: explore_name {
  extends: [explore_name, explore_name, …]
}

Hierarchy

extends

Default Value

None

Accepts

Square brackets containing a comma-separated list of Explore names

Definition

The extends parameter allows you to build upon the content and settings from another Explore, using the other Explore as a starting point. If there are any conflicts, the extending Explore will use its own settings, overriding the settings of the Explore being extended. See Reusing Code with Extends for the details of how Looker does this.

Check out LookML refinements.

Extending a view or an Explore is ideal for scenarios where you want to have multiple versions of the view or Explore. But if your goal is simply to modify a view or an Explore without editing the LookML file that contains it, you may want to use a refinement instead.

You can also use an extends parameter inside a refinement.

See the LookML Refinements documentation page for more information and use cases.

When extending an Explore, it’s important to have the view_name parameter in the Explore that is going to be extended. The view_name parameter defines the view on which an Explore is based. Its default value is the name of the Explore. If the base Explore doesn’t have a view_name specified, it defaults to the Explore name. But this doesn’t work for other Explores that are extending the base Explore, so we would get the “unknown view” error. In order for Looker to use the correct view file, we need to specify it using the view_name parameter. And since this will be needed in any extended version of the Explore, the best practice is to add it to the base Explore so it is consistently referenced any time the Explore is extended.

If your base Explore doesn’t already have a view_name parameter, you can just add the view_name parameter and specify the same value as your Explore’s name.

You may also want to use the view_label parameter in your base and extending Explores. The view_label parameter determines the label under which the view’s fields are grouped in the field picker (see here for an example). If you don’t specify a view_label for your base and extending Explores, they both will use the Explore name from the base Explore.

Example

Here’s an example Explore that’s defined in our model file:

explore: orders { view_name: orders view_label: "Orders" # The normal contents of the Explore follow }

And here we add a new Explore that extends the orders Explore that we defined above:

explore: name_of_the_new_explore { extends: [orders] view_label: "Order Information" # The additional things you want to add or change # in the new Explore }

If you are extending an Explore that is based on an extended view, you will also need to use the from parameter. Add from to the extending Explore and assign it the name of the extended view.

explore: new_explore { extends: [orders] from: extended_orders_view #The normal contents of the Explore follow }

Using Extends to Limit Fields for Different Users

A very handy use case of extending an Explore is to display only a subset of an Explore’s fields to certain users. For example, suppose you have a products Explore with all of the available fields from the joined tables:

explore: products { view_name: products from: products join: inventory_items { type: left_outer sql_on: ${products.id}=${inventory_items.product_id} ;; relationship: many_to_one }   join: order_items { type: left_outer sql_on: ${order_items.inventory_item_id}=${inventory_items.id} ;; relationship: one_to_one } }

If you have a team who only needs to see product category and returns, you can extend the products Explore and use the fields parameter to specify that only the product category and returns fields are to be included:

explore: products_extended { extends: [products] fields: [products.category,order_items.returned_date] }

The products_extended Explore will display only these two fields: products.category and order_items.returned_date.

Extending an Explore Across Models

Explores are usually defined within a model file. If you want to extend an Explore, you can just define the extending Explore in the same model file, as in the examples above.

However, if you want to extend an Explore across multiple models, you must create a separate Explore file to use as a base file. Once you have defined the base Explore in its own file, you can include the Explore file in your model file and extend the Explore in your model file. You can find a detailed example in the Help Center article on Extending Explores to a Different Model.

Since you can include an Explore file in another Explore file, you can also share your base Explore file across multiple other Explore files, if need be.

Explore files will listen to the connection of the model in which they are included. Keep this in mind when you include Explore files in models that are configured with a connection that is different from the Explore file’s parent model. If the schema for the including model’s connection differs from the schema for the parent model’s connection, it can cause query errors.

Things to Consider

When extending an object, be aware that localization rules apply to your extensions as well. If you are extending an object and then defining new labels or descriptions, you should provide localization definitions in your project’s locale strings files. See the Localizing Your LookML Model documentation page for more information.

Top