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 thefrom
(for joins) parameter documentation page.
Usage
explore: explore_name { from: view_name }
Hierarchy
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.