from

LookML
Version

On this Page
Docs Menu

Go to Join Parameter List

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

from can also be used as part of an explore, described here

Usage

from is a child of
join is a child of
joins is a child of
explore
explore: view_name
joins:
join: new_alias_name
...
1st
Tab
2nd
Tab
3rd
Tab
from: underlying_view
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 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 above, the field would appear instead as NEW ALIAS NAME Order Value and be referenced as ${new_alias_name.order_value}

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 joins: - 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 joins: - 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 Its 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 joins: - 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] joins: - 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 joins: - 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
Still have questions?
Go to Discourse - or - Email Support
Top