required_joins

Utilisation

explore: view_name_1 {
  join: view_name_2 { ... }
  join: view_name_3 {
    required_joins: [view_name_2, ...]
  }
}
Hiérarchie
explore
join
required_joins
Valeur par défaut
Aucun

Acceptation
Crochets contenant une liste de jointures séparées par une virgule pour cette exploration

Règles spéciales
Une vue doit être jointe à une exploration avant de pouvoir être référencée dans required_joins.

Définition

required_joins force l'inclusion d'un ou de plusieurs joins dans le code SQL généré par Looker, même si l'utilisateur n'a pas sélectionné de champ dans cette vue jointe. Ce comportement se déclenche chaque fois que l'utilisateur sélectionne un champ dans une vue associée que vous spécifiez. Plusieurs jointures peuvent être nécessaires à l'aide d'une liste d'éléments séparés par une virgule, comme [join_name_a, join_name_b, ...].

Lorsque Looker génère du code SQL pour une requête, il tente de créer le code SQL le plus propre possible et n'utilise que les jointures nécessaires pour les champs qu'un utilisateur sélectionne. Dans l'exemple de diagramme de syntaxe en haut de cette page :

  • Si un utilisateur ne choisit qu'un champ dans view_name_2, il s'agit de la seule vue jointe à l'exploration.
  • Si un utilisateur sélectionne un champ dans view_name_3, le paramètre required_joins de cette jointure entraîne la jointure de view_name_2 à l'exploration.

Voici les principaux cas d'utilisation de required_joins :

Ancienne syntaxe avec sql_on

sql_on n'a pas besoin de required_joins lorsqu'il est utilisé avec la syntaxe ${view_name.looker_dimension_name}. Toutefois, certains anciens modèles utilisent encore la syntaxe view_name.native_column_name. Exemple :

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]
  }
}

Dans cet exemple, chaque fois qu'un utilisateur sélectionne un champ dans customer, la vue order doit également être jointe pour maintenir la relation de jointure appropriée. Si vous oubliez de l'exiger, ces requêtes peuvent toujours fonctionner si l'utilisateur choisit des champs dans toutes les vues requises. Toutefois, d'autres requêtes peuvent générer des données de mauvaise qualité en raison de la mauvaise jointure.

Au lieu d'utiliser required_joins, envisagez de modifier le modèle pour utiliser la syntaxe ${view_name.looker_dimension_name}.

Vous avez besoin ou envie d'écrire du code SQL brut.

Dans certains cas, vous ne pouvez pas ou ne souhaitez pas utiliser la syntaxe ${view_name.looker_dimension_name} avec sql_on. En général, cela est dû au fait que vous souhaitez utiliser les valeurs brutes de votre base de données et éviter toute conversion ou autre manipulation qui se produit avec la syntaxe ${view_name.looker_dimension_name}. Voici un exemple d'utilisation :

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
  }
}

Dans cet exemple, la jointure pre_sign_up_events s'appuie sur les dates de user. Il est donc important de s'assurer que user est joint à l'aide de required_joins.

Au lieu d'utiliser required_joins pour éviter le casting avec des champs de date ou d'heure, envisagez d'utiliser le type date_raw et évitez d'utiliser required_joins.

Difficultés courantes

Une vue doit être jointe à une exploration avant de pouvoir être référencée dans required_joins.

Pour placer une vue dans required_joins, vous devez vous assurer qu'elle est associée à explore où required_joins est utilisé. Par exemple, ceci ne fonctionnera pas :

explore: order_items {
  join: customer {
    sql_on: order.customer_id = customer.id ;;
    required_joins: [order]
  }
}

Ici, order n'a pas été associé à order_items. Il n'est donc pas disponible dans required_joins.