cancel_grouping_fields

Utilisation

explore: explore_name {
  cancel_grouping_fields: [
    fully_scoped_field,
    fully_scoped_field,
    ...
  ]
}

Hiérarchie Fichier de modèle explore cancel_grouping_fields

Valeur par défaut Aucun Acceptation Crochets contenant une liste de noms de champs complets séparés par une virgule Règles spéciales Chaque champ doit être entièrement spécifié à l'aide de la syntaxe view_name.field_name Ne fonctionnera pas correctement si des mesures sont incluses dans la requête Ne peut pas être utilisé avec relationship: one_to_many ni relationship: many_to_many

Définition

cancel_grouping_fields vous permet d'empêcher Looker d'ajouter une clause GROUP BY au code SQL qu'il génère. Si l'un des champs que vous spécifiez est inclus par l'utilisateur, Looker ne regroupe pas les résultats. Cette fonctionnalité est généralement utilisée pour améliorer les performances des requêtes sur des tables très volumineuses. Sauf dans des cas rares et uniques, vous ne devez inclure que les champs qui sont uniques à chaque ligne de la table, comme la clé primaire.

Étant donné que les mesures Looker représentent des fonctions d'agrégation SQL, qui nécessitent une clause GROUP BY pour fonctionner, sachez que cancel_grouping_fields ne fonctionnera avec aucune requête incluant des mesures. De plus, cancel_grouping_fields ne fonctionne pas lorsque relationship: one_to_many ou relationship: many_to_many est utilisé.

Enfin, notez que les champs que vous listez doivent être entièrement délimités. En d'autres termes, ils doivent être écrits sous la forme view_name.field_name, et non simplement field_name.

Exemples

Ne pas regrouper les résultats si l'utilisateur choisit Order ID (ID de commande) dans le sélecteur de champ :

explore: order {
  cancel_grouping_fields: [order.id]
}

Ne pas regrouper les résultats si l'utilisateur choisit Order ID (ID de commande) ou Order Hash (Hachage de commande) dans le sélecteur de champ :

explore: order {
  cancel_grouping_fields: [order.id, order.hash]
}

Ne pas regrouper les résultats si l'utilisateur choisit Person ID (ID de personne) ou DNA ID (ID d'ADN) dans le sélecteur de champ :

explore: person {
  cancel_grouping_fields: [person.id, dna.id]
  join: dna {
    sql_on: ${person.dna_id} = ${dna.id} ;;
    relationship: one_to_one
  }
}

Difficultés courantes

cancel_grouping_fields nécessite des noms de champs complets

La plupart des paramètres de Looker supposent un nom de vue, en fonction de l'endroit où le paramètre est utilisé, si vous écrivez un nom de champ seul. cancel_grouping_fields ne fonctionne pas de cette manière et vous oblige à écrire à la fois le nom de la vue et le nom du champ.

Par exemple, vous pouvez penser que cela fonctionnerait et que id serait interprété comme l'Order ID (ID de commande) qui apparaît dans le sélecteur de champ :

explore: order {
  cancel_grouping_fields: [id]
}

Toutefois, ce n'est pas le cas et vous recevrez une erreur. Vous devez plutôt écrire :

explore: order {
  cancel_grouping_fields: [order.id]
}

cancel_grouping_fields est déclenché lorsqu'un champ spécifié est choisi. Il n'est pas nécessaire de choisir tous les champs.

Si vous spécifiez plusieurs champs dans cancel_grouping_fields, le regroupement sera annulé si un utilisateur sélectionne n'importe quel champ de la liste. L'utilisateur n'est pas obligé de sélectionner tous les champs de la liste. Pour cette raison, les clés primaires à plusieurs colonnes ne fonctionnent pas avec cancel_grouping_fields.

Bon à savoir

cancel_grouping_fields n'est pas nécessaire au bon fonctionnement de Looker. Il permet d'améliorer les requêtes sur les tables volumineuses.

Lorsque vous écrivez du code SQL à la main, la plupart des utilisateurs n'incluent pas de clause GROUP BY, sauf si cela est absolument nécessaire. Looker évite également les clauses GROUP BY inutiles dans certains cas. Si l'une des dimensions de votre requête a été définie comme clé primaire (à l'aide du primary_key paramètre) de l'exploration que vous utilisez, la GROUP BY clause sera supprimée.

Toutefois, dans certains cas, une autre dimension, qui n'est pas la clé primaire, définit toujours une ligne unique. Dans ce cas, Looker peut générer un GROUP BY inutile, car le regroupement par dimensions est un élément fondamental du fonctionnement de Looker. Dans la majorité des cas, cela ne pose aucun problème. Les résultats s'affichent comme prévu et sont rapides.

Toutefois, sur certaines tables très volumineuses, les clauses GROUP BY inutiles peuvent allonger les délais des requêtes. C'est la situation idéale pour utiliser cancel_grouping_fields.