En esta página, se hace referencia al parámetro
from
que forma parte de una unión.
from
también se puede usar como parte de Explorar, descrito en la página de documentación del parámetrofrom
(para Explorar).
Uso
join: Join_name {
from: view_name_2
}
}
Jerarquía
from |
Valor predeterminado
Una vista cuyo nombre coincide con el nombre de la uniónAcepta
El nombre de una vista existente |
Definición
from
especifica el view
que se usará en una unión. Si se omite from
, Looker supondrá que el nombre de la vista subyacente es el mismo que el nombre de la unión.
Por lo general, from
solo se usa si quieres que la combinación y sus campos tengan un nombre diferente al de la vista subyacente. Para aclarar esto, considera un ejemplo en el que se creó una dimensión llamada order_value
en una vista llamada underlying_view
:
- Por lo general, este campo aparece como Valor de pedido de VIEW UNDERLYING en la IU de Explorar y se hace referencia a él en LookML con
${underlying_view.order_value}
. - En el ejemplo de uso anterior, el campo aparecerá como Valor del pedido NEW ALIAS NAME, y se hará referencia a él como
${new_alias_name.order_value}
.
Esta técnica es particularmente útil cuando la misma vista se debe unir a una exploración de varias maneras diferentes.
Ejemplos
Únete a la vista person
en Explorar order
, pero llama a customer
en su lugar:
explore: order {
join: customer {
from: person
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Únete a la vista person
para explorar order
dos veces diferentes: una vez como customer
y una como 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} ;;
}
}
Aspectos para tener en cuenta
from
cambia la forma en que se hace referencia a los campos en Explorar
Como se indicó antes, el uso de from
tiene un impacto importante en la forma en que se hace referencia a los campos. Esto puede causar algunos desafíos cuando se usa un view
en muchos lugares diferentes. Considera el siguiente ejemplo:
explore: order {
join: customer {
from: person
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Aquí, person
se une a order
, pero se llama customer
. Por lo tanto, si necesitas hacer referencia a un campo de customer
dentro de order
, debes usar ${customer.field_name}
.
Si, en una segunda exploración, te vuelves a unir a person
a order
, pero no le cambias el nombre a customer
, la referencia ${customer.field_name}
no funcionará en esa segunda exploración. El enfoque general para este problema es excluir el campo problemático de la segunda exploración mediante fields
. Se vería algo así:
explore: the_second_explore {
fields: [ALL_FIELDS*, -person.problem_field]
join: person {
sql_on: ${the_second_explore.some_field} = ${person.some_field} ;;
}
}
from
suele usarse para unirse a la misma tabla más de una vez a Explorar
En los casos en los que una sola tabla contiene diferentes tipos de entidades, es posible unir una vista a una exploración más de una vez. Supongamos que tienes una exploración de order
y necesitas unir una vista de person
dos veces: una para el cliente y otra para el representante de servicio al cliente. Puedes hacer algo como esto:
explore: order {
join: customer {
from: person
sql_on: ${order.customer_id} = ${customer.id} ;;
}
join: representative {
from: person
sql_on: ${order.representative_id} = ${representative.id} ;;
}
}
El SQL que Looker generaría a partir de este LookML es el siguiente:
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