This article covers an advanced topic and assumes a solid knowledge of LookML.

Extends are a valuable LookML feature that allow us to maintain DRY (don't repeat yourself) LookML code. In Looker, Explores, views, and LookML dashboards can all be extended by leveraging the extends parameter:

The process behind extending LookML objects is relatively straightforward, as detailed in the Extends documentation; however, there are certain advanced use cases that can cause LookML reference errors and unwanted object duplication.

There are a couple of LookML parameters that we can use in these scenarios to eradicate such issues, as detailed in this article. We will refer to the object being extended as the base object, and the object doing the extending as the extending object.

Use Case: Extending a Model

While there is no extends parameter directly for models, we can extend Explores across models by including a model file in another model. However, something that developers often find when employing this method is that including a model in another model file will expose all of the base model's Explores in the extending model's Explore menu, even if they are not explicitly referenced in the extending model. As an example, the e-commerce model below is including a model file from a project for FAA flight data. Although not explicitly defined in the e-commerce model, the FAA Explores are exposed under that model in the Explore drop-down:

When including model files in other models, be careful with parameters like connection. Unlike extends, which resolves LookML between base and extending objects, include will drop the entire model file (including the connection) in,so there will be some conflict. The connection in the included model will override the connection in the including model. Consider only defining the connection in one model, or making a base Explore file that doesn't have a connection parameter, as addressed below.

There are two solutions to this common issue.

Solutions

Requiring Extension

The first possible solution to hiding these base Explores from the extending model is to use extension: required on the base Explores that you wish to not be visible. In this case, extension: required would need to be specified on the FAA flight project Explores. The extension: required parameter will only surface these base Explores if they are being extended. However, this will hide those Explores in the base model as well, which may not be desirable. To make these base Explores visible again, we would need to create a new model file to extend those base Explores, for the sole purpose of unhiding them. In some cases, this may defeat the intention of writing DRY code in the first place.

Explore Files

New in Looker 7.2, you can create generic LookML files.

If you wish to hide the unwanted base Explores in the extending model, while keeping them visible in the base model, we can define the specific base Explore or Explores in a separate .explore.lkml file.

We can then include the Explore file in both the base and extending model files. This will make only the Explores we wish to extend accessible to the model in which they will be extended.

Use Case: An Extending Explore Based on an Extending View

Let's say that we wish to extend an Explore, but want the view of the extending Explore to pull from the base Explore's extending view. An issue developers will often run into in this situation is an 'inaccessible view' or 'inaccessible field' error thrown by the LookML Validator when attempting to join another view to an extending Explore, or joining on a field that exists solely in the extending view:

This is due to the fact that the joins in the base Explore reference the name of the base view, while the joins in the extending Explore reference the extending view name (${events_extended.test_id}). This causes a conflict.

Solution

In the screenshot above, we have the following base Explore, based on the view events:

explore: events {
    view_name: events
        join: users {
            sql_on: ${events.user_id} = ${users.id} ;;
            relationship: many_to_one
        }
    }

We wish to extend this Explore into events_extended, but we want events_extended to reference the extending events view, events_extended. We have defined a new field in events_extended (test_id), on which we want to join an orders view:

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

     dimension: test_id {}

To achieve this, we can apply the from parameter to the extending Explore, which will reference the extending view name. from aliases the original table name in the generated SQL, like so: FROM schema.name AS alias.

This is the only recommended use case for applying the from parameter at the explore level.

In order to pull from the extending view (events_extended) without breaking the join references from the base Explore (events), we 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 use case, applying from: extending_view_name to the extending Explore allows us to 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).

We will continue to reference the base view name events in the join prefixes; but, with from, these references will now pull from events_extended, which contains all of the fields in events, plus the new test_id field.

Conclusion

When using extends to write DRY code, we can leverage the parameters explained above to resolve errors and avoid duplication of objects. When extending Explores, create an .explore.lkml file containing the base Explores, and include the file in another model for extending. If you would like to only expose base Explores or other objects when they are extended, use extension: required on the base Explores that you wish to not be surfaced. In the case of extending an Explore based off of an extending view, leverage the from parameter in the extending Explore to ensure the Explore pulls fields from the desired view without breaking join references from the base Explore.

With these tips in mind, the extended world is your oyster!