User Guide Getting Started Help Center Documentation Community Training
New LookML
Old LookML
New LookML
Looker
  
English
Français
Deutsch
日本語
from (for Joins)

This page refers to the from parameter that is part of a join.

from can also be used as part of an Explore, described on this documentation page.

Usage

explore: view_name {
  join: join_name {
    from: view_name_2
  }
}

Hierarchy

from

Default Value

A view whose name matches the join’s name

Accepts

The name of an existing view

Definition

from determines the view to use in a join. If from is omitted, Looker will assume that the underlying view name is the same as the join name.

Typically from is only used if you want the join 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 technique is particularly useful when the same view needs to be joined to an Explore in several different ways.

Examples

Join the view person to the Explore order, but call it customer instead:

explore: order { join: customer { from: person sql_on: ${order.customer_id} = ${customer.id} ;; } }

Join the view person to the Explore order two different times — once as customer and once as representative:

explore: order { join: customer { from: person sql_on: ${order.customer_id} = ${customer.id} ;; } join: representative { from: person sql_on: ${order.representative_id} = ${representative.id} ;; } }

Common Challenges

## from Changes the Way Fields Are Referenced within an Explore

As noted above, using from has an important impact on the way that fields are referenced. This can cause some challenges when a view is used in many different places. Consider this example:

explore: order { join: customer { from: person sql_on: ${order.customer_id} = ${customer.id} ;; } }

Here person is being joined to order, but it is being called customer. So, if you needed to reference a field from customer within order, you would use ${customer.field_name}. If, in a second Explore, you join person to order again — but don’t rename it to customer — the ${customer.field_name} reference will not work in that second Explore. The general approach to this issue is to exclude the problematic field from the second Explore using fields. It would look something like this:

explore: the_second_explore { fields: [ALL_FIELDS*, -person.problem_field] join: person { sql_on: ${the_second_explore.some_field} = ${person.some_field} ;; } }

Things to Know

from Is Most Often Used to Join the Same Table More Than Once to an Explore

In cases where a single table contains different types of entities, it is possible to join a view to an Explore more than once. Suppose you had an order Explore and needed to join a person view to it twice; once for the customer and once for the customer service representative. You might do something like this:

explore: order { join: customer { from: person sql_on: ${order.customer_id} = ${customer.id} ;; } join: representative { from: person sql_on: ${order.representative_id} = ${representative.id} ;; } }

The SQL that Looker would generate from this LookML is:

SELECT    ...
FROM      order
LEFT JOIN person AS customer
ON        customer.id = order.customer_id
LEFT JOIN person AS representative
ON        representative.id = order.representative_id
Top