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, andLookML dashboards can all be extended with theextends 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, theextends parameter is used within the definition of thetransactions Explore to extend theorders Explore.

This page refers to the object that is being extended as thebase object, and the object that is doing the extending is referred to as theextending object.

Extending a LookML object is a fairly straightforward process, as detailed on theReusing 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 theevents Explore, and you want the view that the extending Explore is based on to use fields from a view that extends the baseevents view. In this example, theevents_extended Explore extends theextends 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, theusers view is joined to the baseevents Explore, while theorders view is joined to the extending Explore,events_extended. However, the join defined in the baseevents Explore referencesevents.user_id, which is a field from the baseevents view. Meanwhile, the join defined in the extendingevents_extended Explore references the fieldevents_extended.test_id, whereevents_extended is the name of an extending view based on theevents view. Thetest_id field that is referenced in the join in theevents_extended Explore definition is defined in the extendingevents_extended view as follows:

include: "events.view.lkml"view: events_extended {  extends: [events]  dimension: test_id {}

Because the join defined in theevents_extended Explore references the name of the extending view,events_extended, theLookML Validator displays aninaccessible view error.

To address this, you can add thefrom parameter to the LookML for the extending Explore and set its value to the name of the extending view,events_extended. Thefrom parameter aliases the original table name in the generated SQL, asFROM schema.name AS alias.

This is the only recommended use case for applying thefrom 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 afrom 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 LookMLfrom: 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 thefrom parameter, you can continue to reference the base view nameevents in the join prefixes, but these references will pull from the extending viewevents_extended, which contains all the fields inevents, plus the newtest_id field.