This page refers to the
type
parameter that is part of a join.
type
can also be used as part of a dimension, described on the Dimension, filter, and parameter types documentation page.
type
can also be used as part of a measure, described on the Measure types documentation page.
type
can also be used as part of a dashboard filter, described on the Dashboard parameters documentation page.
type
can also be used as part of a dashboard element, described on thetype
(for LookML dashboards) parameter documentation page.
Usage
explore: view_name { join: view_name_2 { type: inner } }
Hierarchy
type |
Default Value
left_outer
Accepts
A type of join (cross , full_outer , inner , left_outer )
Special Rules
When you use a type other than left_outer , you might want to use always_join to make sure the resulting rows include your join restrictions
|
Definition
type
lets you describe the type of join that you want to perform.
The possible join type values are described in these sections of this page:
left_outer
(the default value)
The most common join type in Looker is left_outer
(the reason for its frequent use is described in the left_outer
join types are usually preferred section on this page). You may know it from SQL as a LEFT JOIN
. When you use this type
, all rows from the Explore are included and data from the joined view is brought in, if available.
full_outer
The full_outer
join type — which you may know from SQL as a FULL OUTER JOIN
— includes all rows from the Explore and joined view, even if there is no corresponding data from the other view.
inner
The inner
join type — which you may know from SQL as a JOIN
or INNER JOIN
— only includes rows that have matching records in both the Explore and joined view.
cross
The cross
join type — which you may know from SQL as a CROSS JOIN
— is rarely used. It is sometimes helpful for zero-filling or matrix generation. It creates a row for every combination of the Explore and joined view.
Examples
Use a FULL OUTER JOIN
to add user
data to your order
data, even if the user hasn't placed an order:
explore: order {
join: user {
sql_on: ${order.user_id} = ${user.id} ;;
type: full_outer
}
}
Use an INNER JOIN
to add user
data to your event
data, and limit the results to just the events that were generated by a user:
explore: event {
join: user {
sql_on: ${event.user_id} = ${user.id} ;;
type: inner
}
}
Use a CROSS JOIN
to generate all possible combinations of owner
and property
:
explore: property {
join: owner {
sql_on: 1 = 1 ;; # this sql_on condition is required in some dialects,
type: cross # but causes problems in other dialects, try adding or
} # removing if you experience problems with cross joins
}
Things to know
left_outer
join types are usually preferred
When learning and using SQL, many people focus primarily on JOIN
, which is technically known as an "inner join". For this reason, one might assume that type: inner_join
should be used in the majority of cases. However, Looker typically works best with type: left_outer
, which is like using a LEFT JOIN
in SQL.
The reason for this is that the view associated with an Explore (as opposed to the views joined into an Explore) is usually the "primary" data. For example, you might have an Explore based on event information. Some of the events might be generated by your system and other events might be generated by your users. If you join user
into event
using a regular JOIN
, you will only be able to see events that were created by a user, and you'll lose visibility to system events. By using a LEFT JOIN
instead, you'll be able to see all the events, whether or not there is a user associated with them.
You may want to use always_join
if restricting rows is important
When Looker generates SQL for a query, it attempts to create the cleanest SQL possible, and will only use the joins that are necessary for the fields a user selects. When you use type
to define something other than a LEFT JOIN
, you might always want a certain join (or set of joins) to be part of the query, to make sure the resulting rows include your join restrictions. You can achieve this by using the always_join
parameter.