cancel_grouping_fields

Utilisation

explore: explore_name {
  cancel_grouping_fields: [
    fully_scoped_field,
    fully_scoped_field,
    ...
  ]
}
Hiérarchie
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'utilisateur inclut l'un des champs que vous spécifiez, Looker ne regroupe pas les données. Cette fonctionnalité est généralement utilisée pour améliorer les performances des requêtes sur les très grandes tables. Sauf dans des cas rares et uniques, vous ne devez inclure que les champs propres à chaque ligne du tableau, 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, notez 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éfinis. En d'autres termes, ils doivent être écrits sous la forme view_name.field_name et non simplement field_name.

Exemples

Ne regroupez pas les résultats si l'utilisateur sélectionne ID de la commande dans le sélecteur de champs :

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

Ne regroupez pas les résultats si l'utilisateur choisit ID de commande ou Hachage de la commande dans le sélecteur de champ :

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

Ne regroupez pas les résultats si l'utilisateur sélectionne ID de personne ou 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 entièrement définis.

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 pourriez penser que cela fonctionnerait et que id serait interprété comme l'ID de commande qui apparaît dans le sélecteur de champ :

explore: order {
  cancel_grouping_fields: [id]
}

Cependant, ce n'est pas le cas et vous recevrez un message d'erreur. Vous devez é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 que tous les champs soient choisis.

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 tenu de sélectionner tous les champs de la liste. C'est pourquoi 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 grandes tables.

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 paramètre primary_key) de l'exploration que vous utilisez, la clause GROUP BY sera supprimée.

Toutefois, il existe des cas où une autre dimension (qui n'est pas la clé primaire) définit tout de même 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 plupart des cas, cela ne pose aucun problème. Les résultats s'affichent comme vous l'attendez et sont rapides.

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