Troubleshooting an example of an advanced extends use case

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.