This page refers to the
extendsparameter that is part of an Explore.
extendscan also be used as part of a view, as described on this documentation page.
extendscan also be used as part of a LookML dashboard, as described on this documentation page.
extends: [explore_name, explore_name, …]
AcceptsSquare brackets containing a comma-separated list of Explore names
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
extendsparameter 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.
Here’s an example Explore that’s defined in our model file:
And here we add a new Explore that extends the
orders Explore that we defined above:
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.
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:
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:
products_extended Explore will display only these two fields:
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.