always_join

Utilisation

explore: explore_name {
  always_join: [
    view_name,
    view_name,
    ...
  ]
}

Hiérarchie Fichier de modèle explore always_join

Valeur par défaut Aucun Acceptation Crochets contenant une liste de noms de vues séparés par une virgule Règles spéciales Vous devez joindre une vue à explore avant de l'utiliser dans always_join.

Définition

always_join force l'inclusion d'une ou plusieurs jointures 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. Plusieurs jointures peuvent être nécessaires à l'aide d'une liste d'éléments séparés par une virgule, comme [view_name_a, view_name_b, etc].

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. En utilisant always_join, vous pouvez forcer les jointures à se produire quoi qu'il arrive.

always_join peut être utile lorsqu'une jointure est exécutée avec le paramètre type et que la jointure n'est pas une LEFT JOIN. Dans ce cas, la jointure peut être essentielle pour limiter correctement les lignes renvoyées.

Exemples

Assurez-vous que member est toujours associé à event, même si l'utilisateur ne choisit pas de champ dans member. Cela limite les résultats aux événements générés par les membres :

explore: event {
  always_join: [member]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
}

Assurez-vous que member et payment sont toujours associés à event, même si l'utilisateur ne choisit aucun champ dans ces vues. Cela limite les résultats aux événements générés par les membres pour lesquels ils ont déjà payé :

explore: event {
  always_join: [member, payment]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
  join: payment {
    sql_on: ${member.payment_id} = ${payment.id} ;;
    type: inner
  }
}

Difficultés courantes

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

Pour placer une vue dans always_join, assurez-vous qu'elle est jointe à l'exploration où always_join est utilisé. Par exemple, ceci ne fonctionnera pas :

explore: event {
  always_join: [member]
}

Ici, la vue member n'a pas été jointe à event. Elle n'est donc pas disponible dans always_join.

Bon à savoir

Évitez d'appliquer la logique métier dans les jointures si possible

L'approche standard de Looker pour les jointures consiste à utiliser un LEFT JOIN chaque fois que cela est possible. Dans les exemples précédents, nous évitons un LEFT JOIN afin que la logique métier puisse être appliquée dans la jointure elle-même. Dans l'un des exemples, nous avons créé une exploration qui n'incluait que les événements associés aux membres :

explore: event {
  always_join: [member]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
}

La méthode recommandée pour exécuter cette opération dans Looker consiste à utiliser un LEFT JOIN pour obtenir les données d'événement et les données de membre associées de manière simple :

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
  }
}

Vous pouvez ensuite créer une dimension que vous pouvez définir sur "oui" ou "non" pour n'examiner que les événements des membres :

dimension: is_member_event {
  type: yesno
  sql: ${member.id} IS NOT NULL ;;
}

Cette approche permet aux utilisateurs d'examiner tous les événements ou uniquement les événements des membres. Vous n'avez pas forcé les utilisateurs à ne regarder que les événements des membres via la jointure.

Lorsqu'une exploration inclut always_join, la valeur par défaut de full_suggestions passe à yes.

Lorsqu'une exploration inclut le paramètre always_join, la valeur par défaut de full_suggestions passe à yes. La requête de suggestions s'exécute alors à l'aide de la logique Explorer, ce qui signifie que always_join est appliqué pour affiner les suggestions renvoyées. La liste de suggestions est ainsi limitée aux données auxquelles l'utilisateur est censé avoir accès.

Si vous définissez manuellement full_suggestions sur no, la requête de suggestion de filtre ne s'exécutera pas.