Uso
join: view_name_2 { ... }
join: view_name_3 {
required_joins: [
view_name_2
, ...]}
}
Jerarquía
required_joins |
Valor predeterminado
NingunaAcepta
Corchetes que contienen una lista separada por comas de uniones para esta exploraciónReglas especiales
Una vista debe unirse a una exploración antes de que se pueda hacer referencia en required_joins
|
Definición
required_joins
obliga a que se incluya uno o más joins
en el SQL que genera Looker, incluso si el usuario no seleccionó un campo de esa vista unida. Este comportamiento se activa cuando el usuario selecciona un campo de la vista relacionada que especifiques. Se pueden requerir varias uniones mediante una lista separada por comas, como [join_name_a, join_name_b, ...]
.
Cuando Looker genera SQL para una consulta, intenta crear el SQL más limpio posible y solo usará las uniones necesarias para los campos que un usuario selecciona. En el ejemplo del diagrama de sintaxis que se encuentra en la parte superior de esta página, haz lo siguiente:
- Si un usuario solo elige un campo de
view_name_2
, esa será la única vista que se una a Explorar. - Si un usuario selecciona un campo de
view_name_3
, el parámetrorequired_joins
de esa unión hace queview_name_2
se una a Explorar.
Los casos prácticos principales para required_joins
:
Estilo de sintaxis anterior con sql_on
sql_on
no necesita required_joins
cuando se usa con la sintaxis ${view_name.looker_dimension_name}
. Sin embargo, algunos modelos anteriores todavía usan la sintaxis view_name.native_column_name
. Por ejemplo:
explore: order_items {
join: order {
sql_on: order_items.order_id = order.id ;;
}
join: customer {
sql_on: order.customer_id = customer.id ;;
required_joins: [order]
}
}
-
En este ejemplo, cada vez que un usuario selecciona un campo de customer
, también se debe unir la vista order
para mantener la relación de unión adecuada. Si olvidas hacer esta solicitud, podría seguir funcionando si el usuario elige campos de todas las vistas requeridas. Sin embargo, otras consultas pueden dar como resultado datos erróneos debido a la unión incorrecta.
En lugar de usar required_joins
, considera modificar el modelo para usar la sintaxis ${view_name.looker_dimension_name}
.
Necesidad o deseo de escribir SQL sin procesar
Hay algunos casos en los que no puedes o no quieres usar la sintaxis ${view_name.looker_dimension_name}
con sql_on
. Por lo general, esto se debe a que deseas usar los valores sin procesar en tu base de datos y deseas evitar cualquier conversión de tipos o cualquier otra manipulación que ocurra con la sintaxis ${view_name.looker_dimension_name}
. Este es un ejemplo de uso:
explore: order {
join: user {
sql_on: ${order.user_id} = ${user.id} ;;
}
join: pre_sign_up_events {
from: event
sql_on:
${event.user_id} = ${user.id} AND
event.date BETWEEN user.creation_date AND user.sign_up_date ;;
required_joins: [user]
relationship: one_to_many
}
}
-
En este ejemplo, la combinación pre_sign_up_events
se basa en fechas de user
. Por lo tanto, es importante asegurarse de que user
esté unido mediante required_joins
.
En lugar de usar required_joins
para evitar la transmisión con campos de hora o fecha, procura usar el tipo de date_raw
y evita usar required_joins
.
Desafíos habituales
Una vista debe unirse a una exploración antes de que se pueda hacer referencia en required_joins
Para colocar una vista en required_joins
, debes asegurarte de que esté unida a explore
en la que se usa required_joins
. Por ejemplo, esto no funcionará:
explore: order_items {
join: customer {
sql_on: order.customer_id = customer.id ;;
required_joins: [order]
}
}
-
Aquí order
no se unió a order_items
, por lo que no está disponible para su uso en required_joins
.