Uso
explore: view_name_1 {
join: view_name_2 { ... }
join: view_name_3 {
required_joins: [view_name_2, ...]
}
}
|
Jerarquía
required_joins |
Valor predeterminado
Ninguno
Acepta
Corchetes que contienen una lista separada por comas de las uniones para esta exploración
Reglas especiales
Una vista debe unirse a un Explorar antes de que se pueda hacer referencia a ella en required_joins.
|
Definición
required_joins obliga a que se incluyan uno o más joins en el código SQL que genera Looker, incluso si el usuario no seleccionó un campo de esa vista combinada. Este comportamiento se activa cada vez que el usuario selecciona un campo de una vista relacionada que especificas. Se pueden requerir varias uniones con 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 que sean necesarias para los campos que seleccione un usuario. En el ejemplo del diagrama de sintaxis que se encuentra en la parte superior de esta página, se muestra lo siguiente:
- Si un usuario solo elige un campo de
view_name_2, esa sería la única vista unida a la Exploración. - Si un usuario selecciona un campo de
view_name_3, el parámetrorequired_joinsde esa unión hace queview_name_2se una a la exploración.
Los casos de uso principales de required_joins son los siguientes:
Estilo de sintaxis anterior con sql_on
sql_on no necesita required_joins cuando se usa con la sintaxis de ${view_name.looker_dimension_name}. Sin embargo, algunos modelos más antiguos aún 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 requerir estas consultas, es posible que sigan funcionando si el usuario elige campos de todas las vistas obligatorias. Sin embargo, otras consultas pueden generar datos incorrectos de forma silenciosa debido a la unión incorrecta.
En lugar de usar required_joins, considera modificar el modelo para que use la sintaxis ${view_name.looker_dimension_name}.
Necesidad o deseo de escribir código SQL sin procesar
Hay algunos casos en los que no puedes o no quieres usar la sintaxis de ${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 evitar cualquier conversión o manipulación que ocurra con la sintaxis de ${view_name.looker_dimension_name}. A continuación, se muestra 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 unión pre_sign_up_events se basa en las fechas de user. Por lo tanto, es importante asegurarse de que user se una con required_joins.
En lugar de usar required_joins para evitar la transmisión con campos de fecha o hora, considera usar el tipo date_raw y evita usar required_joins.
Desafíos habituales
Una vista debe unirse a un Explorar antes de que se pueda hacer referencia a ella en required_joins.
Para colocar una vista en required_joins, debes asegurarte de que esté unida al explore donde 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 usarse en required_joins.