Dans cette rubrique avancée, nous partons du principe que le lecteur possède une solide connaissance de LookML.
Présentation
À mesure que votre modèle LookML gagne en taille et en complexité, il devient de plus en plus utile de le réutiliser à différents endroits. Le paramètre extends
vous permet de réutiliser du code, ce qui vous permet d'effectuer les opérations suivantes:
- Écrivez du code DRY (ne vous répétez pas) afin de pouvoir définir des éléments au même endroit, ce qui rend votre code plus cohérent et plus rapide à modifier
- Gérer différents jeux de champs pour différents utilisateurs
- Partager des modèles de conception dans différentes parties de votre projet
- Réutiliser des ensembles de jointures, de dimensions ou de mesures dans un projet
Pour étendre un objet LookML, vous devez créer un objet LookML, puis ajouter le paramètre extends
pour indiquer que le nouvel objet est une extension d'un objet existant. Votre projet dispose donc de deux versions de l'objet LookML. En cas de conflit, l'objet d'extension prévaut et remplace les paramètres de l'objet étendu. Pour en savoir plus, consultez la section Détails de l'implémentation pour extends
plus loin sur cette page.
Consultez les améliorations LookML:l'extension d'une vue ou d'une exploration est idéale pour les scénarios dans lesquels vous souhaitez disposer de plusieurs versions de la vue ou de l'exploration. Mais si votre objectif est simplement de modifier une vue ou une exploration sans modifier le fichier LookML qui les contient, vous pouvez utiliser un affinement à la place. Vous pouvez également utiliser un paramètre
extends
dans un filtre. Consultez la page de documentation sur les améliorations de LookML pour en savoir plus et découvrir des cas d'utilisation.
Vous pouvez étendre des vues, des explorations et des tableaux de bord LookML :
Les modèles ne peuvent pas être étendus, et vous ne pouvez pas inclure de fichier de modèle dans un autre fichier de modèle. En revanche, si vous souhaitez réutiliser ou étendre des explorations sur plusieurs modèles, vous pouvez créer un fichier d'exploration distinct, puis inclure ce fichier dans un fichier de modèle.
Consultez les exemples suivants pour savoir comment étendre une exploration et étendre un tableau de bord LookML.
Étendre une exploration
Voici un exemple d'extension d'une exploration:
explore: customer {
persist_for: "12 hours"
}
explore: transaction {
extends: [customer]
persist_for: "5 minutes"
}
Dans cet exemple, nous avons une exploration appelée Customer et nous avons créé une deuxième exploration appelée Transaction qui l'étend. Tout ce qui se trouve dans Customer, y compris ses jointures, est inclus dans Transaction. Tout ce qui se trouve à l'état Transaction le restera.
Notez qu'il y a un conflit: l'exploration Client indique que le paramètre persist_for
devrait être défini sur 12 heures, alors que l'exploration Transaction indique que ce paramètre devrait être de 5 minutes. Pour l'exploration Transaction, le paramètre persist_for: "5 minutes"
est utilisé, car il remplace le paramètre de l'exploration qu'il étend.
Étendre un tableau de bord LookML
Pour étendre un tableau de bord LookML, les tableaux de bord étendus et étendus doivent être inclus dans le fichier de modèle. Si un tableau de bord utilisant le paramètre extends
est inclus dans un fichier de modèle sans le tableau de bord de base qu'il étend, vous obtiendrez une erreur de validation LookML indiquant que le tableau de bord de base est introuvable (entre autres erreurs).
Voici un exemple de fichier de tableau de bord:
Fichier : faa.dashboard.lookml
- dashboard: faa
title: FAA Dashboard
layout: newspaper
elements:
- title: Aircraft Location
name: Aircraft Location
model: e_faa
explore: aircraft
type: looker_map
fields:
- aircraft.zip
- aircraft.count
sorts:
- aircraft.count desc
limit: 500
query_timezone: America/Los_Angeles
series_types: {}
row: 0
col: 0
width: 8
height: 6
Nous pouvons créer un fichier de tableau de bord LookML et étendre le tableau de bord FAA en ajoutant une nouvelle vignette:
Fichier : faa_additional.dashboard.lookml
- dashboard: faa_additional
title: FAA Additional
extends: faa
elements:
- title: Elevation Count
name: Elevation Count
model: e_faa
explore: airports
type: looker_scatter
fields:
- airports.elevation
- airports.count
sorts:
- airports.count desc
limit: 500
query_timezone: America/Los_Angeles
row: 0
col: 8
width: 8
height: 6
Comme il étend le tableau de bord FAA, le tableau de bord FAA Additional inclura toutes les vignettes définies dans le fichier faa.dashboard.lookml
. De plus, le tableau de bord FAA Additional contiendra toutes les vignettes définies dans son propre fichier faa_additional.dashboard.lookml
.
Le moyen le plus simple de créer un tableau de bord LookML consiste à obtenir le code LookML à partir d'un tableau de bord défini par l'utilisateur. Vous pouvez également utiliser cette technique pour obtenir le code LookML de chaque vignette de tableau de bord. Si vous utilisez cette méthode, assurez-vous que les positions de vos tuiles ne se chevauchent pas. Dans l'exemple ci-dessus, les vignettes se trouvent toutes les deux sur la ligne supérieure du tableau de bord, ce qui est indiqué par row: 0
:
Fichier : faa.dashboard.lookml
row: 0
col: 0
width: 8
height: 6
Toutefois, la nouvelle vignette que nous ajoutons au tableau de bord FAA Additional est dans col: 8
. Elle s'affiche donc à côté de la vignette dans le tableau de bord étendu:
Fichier : faa_additional.dashboard.lookml
row: 0
col: 8
width: 8
height: 6
C’est une chose facile à manquer, car ces éléments se trouvent dans des fichiers de tableau de bord différents. Par conséquent, si vous ajoutez des vignettes à un tableau de bord étendu, vérifiez qu'il n'y a pas de conflits de positionnement entre les vignettes du tableau de bord étendu et celles du tableau de bord étendu.
Extension requise
Vous pouvez utiliser le paramètre extension: required
pour indiquer qu'un objet LookML nécessite une extension, ce qui signifie qu'il ne peut pas être utilisé seul. Un objet avec extension: required
n'est pas visible par les utilisateurs. Il sert uniquement de point de départ pour être étendu par un autre objet LookML. Le paramètre extension
est compatible avec les explorations, les vues et les tableaux de bord LookML.
Un explore
avec extension: required
ne peut pas être utilisé en tant que explore_source
pour un test de données. Le programme de validation LookML génère une erreur indiquant que explore_source
est introuvable.
Utiliser des métadonnées pour afficher les extensions d'un objet
Vous pouvez cliquer sur un paramètre explore
ou view
dans l'IDE Looker et utiliser le panneau des métadonnées pour afficher les extensions de l'objet ou pour voir quel objet il étend. Pour en savoir plus, consultez la page de documentation Métadonnées des objets LookML.
Détails de l'implémentation pour extends
Voici les étapes suivies par Looker pour étendre un objet LookML:
- Copiez l'objet à étendre: Looker crée une copie du code LookML de la vue, de l'exploration ou du tableau de bord LookML à développer. Cette nouvelle copie est l'objet d'extension.
- Fusionnez le code LookML des deux copies: Looker fusionne le code LookML de l'objetExtendedétendusing.
- Résolvez les conflits entre les copies: dans la plupart des cas, si un élément LookML est défini à la fois dans l'objet étendu et dans l'objet étendant, la version de l'objet étendu est utilisée. Toutefois, dans d'autres cas, les extensions combinent les valeurs des paramètres au lieu de les remplacer. Pour en savoir plus, consultez la section Combiner des paramètres sur cette page.
- Appliquer le code LookML: une fois tous les conflits résolus, Looker interprète le code LookML résultant à l'aide de la logique standard. En d'autres termes, Looker utilisera tous les paramètres par défaut et toutes les hypothèses standard comme avec n'importe quelle autre vue, exploration ou tableau de bord LookML.
Les sections suivantes présentent les spécificités de ces étapes, en étendant une vue à titre d'exemple. Voici le code LookML de notre vue de base, la vue User (Utilisateur) :
view: user {
suggestions: yes
dimension: name {
sql: ${TABLE}.name ;;
}
dimension: status {
sql: ${TABLE}.status ;;
type: number
}
}
Voici le code LookML de la vue User with Age Extensions (Utilisateur avec extensions d'âge), qui étend la vue User (Utilisateur) :
include: "/views/user.view"
view: user_with_age_extensions {
extends: [user]
suggestions: no
dimension: age {
type: number
sql: ${TABLE}.age ;;
}
dimension: status {
type: string
}
}
Étape 1: Copiez le code LookML
Dans ce cas, la vue user
est étendue dans la vue user_with_age_extensions
. Comme user
est la vue étendue, une copie de celle-ci est créée avant la fusion. Il n'est pas particulièrement important de savoir qu'une copie est créée. Il est important de savoir que la vue user
d'origine reste inchangée et qu'elle peut être utilisée normalement.
Étape 2: Fusionner les copies
L'étape suivante consiste à fusionner tout le code LookML de la vue étendue (user
) dans la vue d'extension (user_with_age_extensions
). Il est important de comprendre la nature de cette fusion, qui est simplement une fusion d'objets LookML. Concrètement, cela signifie que tout code LookML explicitement écrit est fusionné, mais les valeurs LookML par défaut que vous n'avez pas écrites ne sont pas fusionnées. En quelque sorte, c'est juste le texte du code LookML qui est en train d'être assemblé, sans aucune signification de ce texte.
Étape 3: Résolvez les conflits
La troisième étape consiste à résoudre les conflits entre les vues fusionnées.
Dans la plupart des cas, si un élément LookML est défini à la fois dans l'objet étendu et dans l'objet étendu, la version de l'objet d'extension est utilisée. Toutefois, dans d'autres cas, les extensions combinent les valeurs des paramètres au lieu de les remplacer. Pour en savoir plus, consultez la section Combiner des paramètres sur cette page.
Dans l'exemple user_with_age_extensions
, aucun des paramètres n'est additif et aucun option de liste ni sql
mot clé spécial n'est spécifié. Par conséquent, les valeurs de paramètre dans la vue étendue remplacent celles de la vue étendue:
- Le nom de la vue étendue (
user_with_age_extensions
) remplace celui de la vue étendue (user
). - La valeur d'extension pour
suggestions: no
remplace la valeur étenduesuggestions: yes
. - La vue étendue comporte une dimension appelée
age
, qui n'existe pas dans la vue étendue (pas de conflit). - La vue étendue comporte une dimension appelée
name
, qui n'existe pas dans la vue étendue (pas de conflit). - La valeur
type: string
de la dimensionstatus
dans la vue étendue remplace la valeurtype: number
dans la vue étendue. - La dimension
status
comporte un paramètresql
, qui n'existe pas dans la vue étendue (pas de conflit).
Le fait que les valeurs LookML par défaut ne soient pas encore prises en compte est important, car vous ne devez pas faire l'erreur de penser que les conflits entre les valeurs par défaut sont en train d'être résolus. En réalité, ils sont simplement ignorés à cette étape. C'est pourquoi nous devons explicitement ajouter des paramètres supplémentaires lors de l'extension des objets:
- Lorsque nous étendons une vue, nous ajoutons les paramètres
sql_table_name
etinclude
. - Lorsque nous étendons une exploration, nous ajoutons les paramètres
view_name
etview_label
.
Dans cet exemple, nous n'avons pas ajouté sql_table_name
à la vue User (Utilisateur), ce qui va causer des problèmes à l'étape suivante.
Étape 4: Interprétez le code LookML normalement
À la dernière étape, le code LookML obtenu est interprété comme normal, y compris toutes les valeurs par défaut. Dans cet exemple, la vue LookML résultante serait interprétée de la manière suivante:
include: "/views/user.view"
view: user_with_age_extensions {
suggestions: no
dimension: age {
type: number
sql: ${TABLE}.age ;;
}
dimension: name {
sql: ${TABLE}.name ;;
}
dimension: status {
sql: ${TABLE}.status ;;
type: string
}
}
Notez que le code LookML résultant inclut view: user_with_age_extensions
, mais pas de paramètre sql_table_name
. Par conséquent, Looker suppose que la valeur de sql_table_name
est égale au nom de la vue.
Le problème est qu'il n'existe probablement pas de table appelée user_with_age_extensions
dans notre base de données. C'est pourquoi nous devons ajouter un paramètre sql_table_name
à toute vue qui va être étendue. L'ajout de view_name
et view_label
aux explorations étendues permet d'éviter des problèmes similaires.
Combiner des extensions
Il existe plusieurs façons d'exploiter les objets LookML avec des extensions:
- Un objet peut étendre plusieurs autres objets.
- Un objet d'extension peut lui-même être étendu.
- Les extensions peuvent être utilisées dans les améliorations (consultez la page de documentation sur les affinages LookML pour en savoir plus).
Pour voir un exemple de cas d'utilisation avancé et lire les conseils de dépannage, consultez la page Dépannage d'un exemple de cas d'utilisation avancé de
extends
dans les bonnes pratiques.
Étendre plusieurs objets en même temps
Il est possible d'étendre plusieurs tableaux de bord, vues ou explorations à la fois. Exemple :
explore: orders {
extends: [user_info, marketing_info]
}
# Also works for dashboards and views
Le processus d'extension fonctionne exactement comme décrit dans l'exemple d'implémentation, mais il existe une règle supplémentaire concernant la résolution des conflits. En cas de conflit entre les éléments listés dans le paramètre extends
, la priorité est donnée aux éléments listés en dernier. Ainsi, dans l'exemple ci-dessus, en cas de conflit entre user_info
et marketing_info
, l'exploration marketing_info
l'emporterait.
Enchaînement de plusieurs extensions
Vous pouvez également enchaîner autant d'extensions que vous le souhaitez. Exemple :
explore: orders {
extends: [user_info]
...
}
explore: user_info {
extends: [marketing_info]
...
}
Là encore, le processus d'extension fonctionne exactement comme décrit dans l'exemple d'implémentation, avec une règle supplémentaire concernant la résolution des conflits. En cas de conflit, la priorité est donnée au dernier élément de la chaîne d'extensions. Dans cet exemple :
orders
aurait la priorité suruser_info
etmarketing_info
.user_info
aurait la priorité surmarketing_info
.
Combiner des paramètres
Dans la plupart des cas, si un élément LookML est défini à la fois dans l'objet étendu et dans l'objet étendu, la version de l'objet d'extension est utilisée. C'est le cas dans l'exemple d'implémentation présenté sur cette page.
Toutefois, dans les cas suivants, les extensions combine les valeurs de paramètres au lieu de les remplacer:
- Pour les paramètres additifs
- Avec le mot clé de la liste
EXTENDED*
- Avec le mot clé
${EXTENDED}
pour le paramètresql
Certains paramètres se cumulent
Dans de nombreux cas, si l'objet d'extension contient le même paramètre que l'objet étendu, les valeurs de l'objet étendu remplacent celles de l'objet étendu. Toutefois, les extensions peuvent être additives pour certains paramètres. En d'autres termes, les valeurs de l'objet d'extension sont utilisées conjointement avec celles de l'objet étendu.
Les paramètres suivants sont additifs:
Pour les dimensions et les mesures:
Pour les paramètres:
Pour les tables dérivées:
Pour les vues:
Pour les explorations:
Dans l'exemple suivant, la vue carriers
comporte une dimension name
avec un paramètre link
:
view: carriers {
sql_table_name: flightstats.carriers ;;
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Google {{ value }}"
url: "http://www.google.com/search?q={{ value }}"
icon_url: "http://google.com/favicon.ico"
}
}
}
Voici la vue carriers_extended
, qui étend la vue carriers
. La vue carriers_extended
comporte également une dimension name
avec des paramètres différents dans le paramètre link
:
include: "/views/carriers.view.lkml"
view: carriers_extended {
extends: [carriers]
dimension: name {
sql: ${TABLE}.name ;;
type: string
link: {
label: "Dashboard for {{ value }}"
url: "https://docsexamples.dev.looker.com/dashboards/307?Carrier={{ value }}"
icon_url: "https://www.looker.com/favicon.ico"
}
}
}
Dans la vue carriers_extended
, les deux paramètres link
sont additifs. La dimension name
affiche donc les deux liens.
Options supplémentaires avec listes
Lorsque vous travaillez avec des listes, vous pouvez choisir de les combiner au lieu de faire en sorte que la liste des objets qui s'étende soit la plus performante. Prenons l'exemple de cette extension simple avec une liste en conflit appelée animals
:
view: pets {
extends: fish
set: animals {
fields: [dog, cat]
}
}
view: fish {
set: animals {
fields: [goldfish, guppy]
}
}
Dans ce cas, la vue pets
effectue l'extension et va donc gagner. animals
contient donc [dog, cat]
. Toutefois, en utilisant l'ensemble spécial EXTENDED*
, vous pouvez combiner les listes:
view: pets {
extends: fish
set: animals {
fields: [dog, cat, EXTENDED*]
}
}
view: fish {
set: animals {
fields: [goldfish, guppy]
}
}
La liste animals
contient maintenant [dog, cat, goldfish, guppy]
.
Combiner au lieu de remplacer lors de la résolution des conflits
Dans la plupart des cas, en cas de conflit pendant l'extension, l'objet qui a été étendu l'emporte. Prenons par exemple cette extension simple:
view: product_short_descriptions {
extends: products
dimension: description {
sql: ${TABLE}.short_description ;;
}
}
view: products {
dimension: description {
sql: ${TABLE}.full_description ;;
}
}
Vous pouvez constater qu'il existe un conflit entre le paramètre sql
dans la dimension description
. En règle générale, la définition de product_short_descriptions
remplace simplement la définition de products
, car c'est elle qui effectue l'extension.
Toutefois, vous pouvez également choisir de combine les définitions si vous le souhaitez. Pour ce faire, utilisez le mot clé ${EXTENDED}
comme suit:
view: product_short_descriptions {
extends: products
dimension: description {
sql: LEFT(${EXTENDED}, 50) ;;
}
}
view: products {
dimension: description {
sql: ${TABLE}.full_description ;;
}
}
Le conflit du paramètre sql
sera désormais traité différemment. Au lieu que la définition product_short_descriptions
l'emporte, la définition de products
est insérée à l'endroit où ${EXTENDED}
est utilisé. Dans ce cas, la définition obtenue pour description
sera LEFT(${TABLE}.full_description, 50)
.
Éléments à prendre en compte
Projets avec localisation
Lorsque vous étendez un objet, sachez que les règles de localisation s'appliquent également à vos extensions. Si vous étendez un objet, puis définissez de nouveaux libellés ou descriptions, vous devez fournir des définitions de localisation dans les fichiers de chaînes de paramètres régionaux de votre projet. Pour en savoir plus, consultez la page de documentation Localiser votre modèle LookML.