from (for Explores)

This page refers to the from parameter that is part of an Explore.

from can also be used as part of a join, described on the from (for joins) parameter documentation page.

Usage

explore: explore_name {
  from: view_name
}

Hierarchy Model File explore from

Default Value A view whose name matches the Explore's name Accepts The name of an existing view

Definition

from determines the view that will define the fields of an Explore. If from is omitted, Looker will assume that the underlying view name is the same as the Explore name. Typically from is only used if you want the Explore and its fields to have a different name than the underlying view.

To make this more clear, consider an example where a dimension called order_value has been created in a view called underlying_view:

• This field would typically appear as UNDERLYING VIEW Order Value in the Explore UI, and would be referenced in LookML with ${underlying_view.order_value}.
• In the usage example given, the field would appear instead as NEW ALIAS NAME Order Value and be referenced as ${new_alias_name.order_value}.

Examples

Add an option to the Explore menu called Customer based on the view called user:

explore: customer {
  from: user
}

Common challenges

from, view_name, and label are often confused but have different behaviors

As seen in the preceding examples, from has many effects on the way that an Explore is labeled and the way that fields are referenced. There is also a view_name parameter and a label parameter that have similar, but different, effects.

Using from

You should use this option if you want to create multiple Explores from the same view and also want to reference fields differently for each Explore:

explore: customer {
  from: user
}
# Would appear in the Explore menu as 'Customer'
# Fields would appear like 'Customer Name'
# You would reference fields like ${customer.name}

explore: buyer {
  from: user
}
# Would appear in the Explore menu as 'Buyer'
# Fields would appear like 'Buyer Name'
# You would reference fields like ${buyer.name}

The underlying reason for this behavior is that with from: user, the generated SQL aliases the original table name, like this: FROM schema.users AS customer.

Using view_name

You should use this option if you want to create multiple Explores from the same view, and you want to reference fields the same way for each Explore:

explore: customer {
  view_name: user
}
# Would appear in the Explore menu as 'Customer'
# Fields would appear like 'User Name'
# You would reference fields like ${user.name}

explore: buyer {
  view_name: user
}
# Would appear in the Explore menu as 'Buyer'
# Fields would appear like 'User Name'
# You would reference fields like ${user.name}

The underlying reason for this behavior is that with view_name: user, the generated SQL uses the original table name, like this: FROM schema.users AS users.

Using label

You should use this option if you don't need to create multiple Explores from the same view, but want the Explore's name to appear differently in the Explore menu:

explore: user {
  label: "Customer"
}
# Would appear in the Explore menu as 'Customer'
# Fields would appear like 'User Name'
# You would reference fields like ${user.name}

Things to know

from is rarely used with explore

It's not very common to use from to re-name an Explore. Although there are legitimate use cases, if you find yourself wanting to use this parameter, consider if you can simply rename the underlying view instead. It's much more common to rename joins using the join-level from parameter.