This page refers to the
explore
parameter that is part of a model.
explore
can also be used as part of a dashboard filter, described on the Dashboard parameters documentation page.
explore
can also be used as part of a dashboard element. A representative example of its usage is provided on the Column chart parameters for LookML dashboards documentation page.
Usage
Hierarchy
explore |
Default Value
None
Accepts
The name of an existing view, or a name for the explore when using from
Special Rules
explore names must be unique within a given model
|
Definition
If there is a plus sign (
+
) in front of the Explore name, such asexplore: +orders
, that is a refinement of an Explore. See the LookML refinements documentation page for more information.
explore
adds an existing view to Looker's menu of Explores as described on the LookML terms and concepts documentation page. As a best practice, an Explore should be defined inside of a model file.
Explores are typically named after an existing view. However, if you want to have multiple Explores based on the same view, you can add a from
parameter to the Explore. In that case, the Explore can be given any valid name, which includes only lowercase letters (a-z), digits (0-9), and underscores.
explore
plays an important role in the SQL that Looker generates. Suppose a user chooses Customers from the Explore menu and runs a query. This customers
Explore is based on the view called customers
, which is associated with a database table. That table is placed in the FROM
clause of the user's SQL query.
explore
can have many child parameters that affect the display and filter behavior and that specify adding joins for the Explore. If an Explore includes one or more joins, then those joins can have join parameters that specify the desired join behavior.
Examples
Add an option to the Explore menu based on the view called users
:
explore: users {
# additional explore parameters go here
}
Add an option to the Explore menu called Events based on the view called user_events
:
explore: events {
from: user_events
}
Common challenges
explore
needs to reference an existing view name
You cannot define the database table, dimensions, measures, and other fields that are part of a view via an explore
parameter. Instead, you first need to define a view using the view
parameter. Then you can reference the name of that view in explore
.
explore
needs to reference the view name, not its filename
Typically, the name of a view is the same as the view file where the view is defined. This is not required — the view name and view filename can be different.
For example, you have a view called users
defined inside of a file called company_users
. The view file company_users
looks like this:
view: users { ... }
You then add the users
view to the Explore menu with:
explore: users { ... }
Even though the users
view is inside of a file called company_users
, the name of the file does not matter. Only the name of the view in the view
parameter matters.
When you use a measure of
type: count
in an Explore, the visualization labels the resulting values with the view name rather than the word "Count." To avoid confusion, we recommend pluralizing your view name, selecting Show Full Field Name under Series in the visualization settings, or using aview_label
with a pluralized version of your view name.
Things to know
explore
is usually used with additional parameters
It's possible to use explore
by itself, without additional parameters. In practice, you typically see explore
used with additional options. For example, it's very common to join
additional views into an Explore.
All of the additional parameters that are associated with explore
are found here. The parameters that can be used for a join
within an Explore are found here.