This page covers an advanced topic and assumes a solid knowledge of LookML on the part of the reader.
Extends is a valuable LookML feature that allows you to maintain DRY (don't repeat yourself) LookML code. In Looker, Explores, views, and LookML dashboards can all be extended with the extends
parameter within a model file, such as in the following example:
explore: orders { view_name: orders join: users { type: left_outer sql_on: %{orders.user_id} = ${users.id} ;; relationship: many_to_one } } explore: transactions { extends: [orders] }
In this example, the extends
parameter is used within the definition of the transactions
Explore to extend the orders
Explore.
This page refers to the object that is being extended as the base object, and the object that is doing the extending is referred to as the extending object.
Extending a LookML object is a fairly straightforward process, as detailed on the Reusing code with extends documentation page. However, there are some advanced use cases that can cause LookML reference errors and unwanted object duplication. This page provides an example of how extending an Explore based on a view that extends another view can result in LookML reference errors, as well as tips that can help eliminate such issues.
Use case: Extending an Explore based on an extending view
Suppose you want to extend the events
Explore, and you want the view that the extending Explore is based on to use fields from a view that extends the base events
view. In this example, the events_extended
Explore extends the extends
Explore, as shown in the following example LookML:
explore: events { view_name: events join: users { type: left_outer sql_on: ${events.user_id} = ${users.id} ;; relationship: many_to_one } } explore: events_extended { extends: [events] join: orders { sql_on: ${events_extended.test_id} = ${orders.id} ;; relationship: many_to_one }
In this example, the users
view is joined to the base events
Explore, while the orders
view is joined to the extending Explore, events_extended
. However, the join defined in the base events
Explore references events.user_id
, which is a field from the base events
view. Meanwhile, the join defined in the extending events_extended
Explore references the field events_extended.test_id
, where events_extended
is the name of an extending view based on the events
view. The test_id
field that is referenced in the join in the events_extended
Explore definition is defined in the extending events_extended
view as follows:
include: "events.view.lkml" view: events_extended { extends: [events] dimension: test_id {}
Because the join defined in the events_extended
Explore references the name of the extending view, events_extended
, the LookML Validator displays an inaccessible view
error.
To address this, you can add the from
parameter to the LookML for the extending Explore and set its value to the name of the extending view, events_extended
. The from
parameter aliases the original table name in the generated SQL, as FROM schema.name AS alias
.
This is the only recommended use case for applying the from
parameter at the Explore level.
To pull from the extending view (events_extended
) without breaking the join references from the base Explore (events
), you can add a from
parameter that maps to the extending view:
explore: events_extended { extends: [events] from: events_extended join: orders { relationship: many_to_one sql_on: ${events.test_id} = ${orders.id} ;; } }
In this example, applying the LookML from: events_extended
to the LookML for the extending Explore lets you continue referencing the base view (events
) in the extending Explore, while redirecting those references to pull from the extending version of that view (events_extended
).
With the use of the from
parameter, you can continue to reference the base view name events
in the join prefixes, but these references will pull from the extending view events_extended
, which contains all the fields in events
, plus the new test_id
field.