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 theextends
(for views) parameter documentation page.
extends
can also be used as part of a LookML dashboard, as described on the Dashboard parameters documentation page.
Usage
extends: [explore_name, explore_name, …]
}
Hierarchyextends |
Default ValueNoneAcceptsSquare brackets containing a comma-separated list of Explore names |
Definition
The extends
parameter lets you 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 the Reusing code with extends
documentation page 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 anextends
parameter inside a refinement. See the LookML refinements documentation page for more information and use cases.
When you’re 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 the view_label
(for Explores) parameter documentation page 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:
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 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:
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.
Using metadata to see extensions for an object
If your Looker admin has enabled the IDE Metadata Sidebar Labs feature, you can click on an explore
or a view
parameter in the Looker IDE and use the metadata panel to see any extensions on the object, or to see what object it extends. See the Metadata for LookML objects documentation page for information.
Things to consider
Some parameters are additive
In many cases, if the extending object contains the same parameter as the object that is being extended, the extending object’s values will override the parameter values of the extended object. But extensions can be additive for some parameters, meaning that the values from the extending object are used in conjunction with the values from the extended object.
The following Explore parameters are additive:
access_filter
aggregate_table
extends
(you can chain together multipleextends
)join
query
In the following example, the aircraft_base
Explore uses the join
parameter to join the aircraft
view with the aircraft_types
view:
And the aircraft_extended
Explore extends the aircraft_base
Explore. In addition, the aircraft_extended
Explore has a join
parameter that joins in the aircraft_engine_types
view:
The join
parameter is additive, so the resultant Explore will display the views joined in the base Explore, plus the views joined into the extending Explore. In this case, the aircraft_extended
Explore contains the aircraft
view, the aircraft_types
view, and the aircraft_engine_types
view:
Projects with localization
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.