Réutiliser du code avec des extensions

Il s'agit d'une section avancée qui suppose que le lecteur possède de solides connaissances 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:

  • Écrire du code DRY (ne vous répétez pas) afin de pouvoir définir des éléments en un seul endroit, ce qui rend votre code plus cohérent et plus rapide à modifier
  • Gérer différents ensembles 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. Cela signifie que votre projet comportera deux versions de l'objet LookML. En cas de conflit, l'objet d'extension est prioritaire 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.

Découvrir les améliorations de LookML:l'extension d'une vue ou d'une exploration est idéale dans les cas où vous souhaitez disposer de plusieurs versions de la vue ou de l'exploration. En revanche, si votre objectif est simplement de modifier une vue ou une exploration sans modifier le fichier LookML qui la contient, vous pouvez utiliser un filtre. Vous pouvez également utiliser un paramètre extends dans un filtre. Consultez la page de documentation sur les affinements LookML pour en savoir plus et découvrir des cas d'utilisation.

Vous pouvez étendre les vues, les explorations et les 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. À la place, 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 d'exploration dans un fichier de modèle.

Consultez les exemples suivants d'extension d'une exploration et d'extension d'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 Client, comme ses jointures, est inclus dans Transaction. Tout ce qui se trouve dans Transaction le restera dans Transaction.

Notez toutefois un conflit: l'exploration Client indique que le paramètre persist_for doit être défini sur 12 heures, tandis que l'exploration Transaction indique qu'il doit être défini sur 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.

Extension d'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 (parmi d'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

Étant donné qu'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 à récupérer 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 vignettes de tableau de bord individuelles. Si vous utilisez cette méthode, assurez-vous que les positions de vos tuiles ne se chevauchent pas. Dans les exemples faa.dashboard.lookml et faa_additional.dashboard.lookml, les vignettes se trouvent toutes les deux sur la ligne supérieure du tableau de bord, comme indiqué par row: 0:

Fichier : faa.dashboard.lookml


    row: 0
    col: 0
    width: 8
    height: 6

Cependant, la nouvelle vignette que nous ajoutons au tableau de bord FAA Additional se trouve dans col: 8 et s'affiche donc à côté de la vignette du tableau de bord étendu:

Fichier : faa_additional.dashboard.lookml


    row: 0
    col: 8
    width: 8
    height: 6

C'est une chose facile à manquer, puisque 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 les vignettes du tableau de bord étendu.

Prolongation requise

Vous pouvez utiliser le paramètre extension: required pour signaler qu'un objet LookML nécessite une extension, ce qui signifie que l'objet ne peut pas être utilisé seul. Un objet associé à un extension: required n'est pas visible par les utilisateurs de lui-même. 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é comme explore_source pour un test de données. L'outil LookML Validator 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 voir les extensions de l'objet ou l'objet qu'il étend. Pour en savoir plus, consultez la page de documentation Métadonnées pour les objets LookML.

Détails d'implémentation pour extends

Voici les étapes qu'effectue Looker lors de l'extension d'un objet LookML:

  1. Copier l'objet en cours d'extension: Looker crée une copie du code LookML pour la vue, l'exploration ou le tableau de bord LookML en cours d'extension. Cette nouvelle copie est l'objet d'extension.
  2. Fusionner le code LookML des deux copies: Looker fusionne le code LookML de l'objet étendu dans l'objet d'extension.
  3. 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 d'extension, c'est la version de l'objet d'extension qui 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.
  4. Appliquer le code LookML: une fois tous les conflits résolus, Looker interprète le code LookML obtenu en suivant la logique standard. En d'autres termes, Looker utilisera tous les paramètres par défaut et hypothèses standards comme pour toute 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 à la vue user_with_age_extensions. Comme user est la vue en cours d'extension, une copie de celle-ci est créée avant la fusion. Il n'est pas particulièrement important de savoir qu'une copie est effectuée. Il est important de savoir que la vue user d'origine reste inchangée et 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 la 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 le sont pas. D'une certaine manière, c'est le texte du LookML qui est en train de s'assembler, et rien de ce qu'il signifie.

É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 d'extension, 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 aucune option de liste spéciale ni aucun mot clé sql n'est spécifié. Par conséquent, les valeurs de paramètre dans la vue étendue remplaceront les valeurs de paramètre dans la vue étendue:

  • Le nom de la vue étendue (user_with_age_extensions) remplace le nom de la vue étendue (user).
  • La valeur d'extension de suggestions: no remplace la valeur d'extension suggestions: yes.
  • La dimension de l'affichage étendu, appelée age, n'existe pas dans la vue étendue (sans conflit).
  • La vue étendue possède une dimension appelée name, qui n'existe pas dans la vue d'extension (sans conflit).
  • La valeur type: string de la dimension status dans la vue d'extension remplace la valeur type: number dans la vue étendue.
  • La dimension status comporte un paramètre sql, qui n'existe pas dans la vue d'extension (sans conflit).

Le fait que les valeurs LookML par défaut ne soient pas encore prises en compte est important, car vous ne voulez pas faire l'erreur de penser que les conflits entre les valeurs par défaut sont en train de se résoudre. En réalité, ils sont simplement ignorés à cette étape. C'est pourquoi nous devons explicitement ajouter des paramètres supplémentaires lorsque nous étendons des objets:

Dans cet exemple, nous n'avons pas ajouté sql_table_name à la vue Utilisateur, ce qui posera des problèmes à l'étape suivante.

Étape 4: Interpréter le code LookML normalement

Lors de la dernière étape, le code LookML obtenu est interprété comme normal, y compris toutes les valeurs par défaut. Dans cet exemple particulier, la vue LookML résultante serait interprétée comme suit:

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 obtenu inclut view: user_with_age_extensions, mais aucun paramètre sql_table_name. Par conséquent, Looker part du principe que la valeur de sql_table_name est égale au nom de la vue.

Le problème est qu'il n'y a probablement pas de table 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 sera étendue. L'ajout de view_name et view_label aux explorations qui seront étendues évitent des problèmes similaires.

Combiner des extensions

Il existe plusieurs façons d'exploiter les objets LookML avec des extensions:

Pour voir un exemple de cas d'utilisation avancé et lire des conseils de dépannage, consultez la page Bonnes pratiques de dépannage d'un cas d'utilisation extends avancé.

Étendre plusieurs objets à la fois

Il est possible d'étendre simultanément plusieurs tableaux de bord, vues ou explorations. 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, à ceci près qu'il existe une règle supplémentaire concernant la résolution des conflits. En cas de conflit entre plusieurs éléments listés dans le paramètre extends, la priorité est accordée aux derniers éléments. Ainsi, dans l'exemple précédent, en cas de conflits entre user_info et marketing_info, l'exploration marketing_info l'emporte.

Enchaînement de plusieurs extensions

Vous pouvez également enchaîner autant de longueurs 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'extension. Dans cet exemple :

  • orders aurait priorité sur user_info et marketing_info.
  • user_info aurait une priorité sur marketing_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 d'extension, 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 des paramètres au lieu de les remplacer:

Certains paramètres s'ajoutent les uns aux autres

Dans de nombreux cas, si l'objet étendu 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, ce qui signifie que les valeurs de l'objet étendu sont utilisées conjointement avec celles de l'objet étendu.

Les paramètres suivants sont additifs:

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 s'ajoutent les uns aux autres. La dimension name affiche donc les deux liens.

Options supplémentaires avec les listes

Lorsque vous travaillez avec des listes, vous pouvez choisir de les combiner plutôt que de faire en sorte que la liste d'objets étendues soit gagnante. Prenons 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 le cas présent, la vue pets effectue l'extension et gagne donc, ce qui fait que animals contient [dog, cat]. Toutefois, en utilisant l'ensemble spécial EXTENDED*, vous pouvez combiner les listes à la place:

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 conflits pendant l'extension, l'objet d'extension l'emporte. Prenons l'exemple de 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 y a un conflit entre le paramètre sql et la dimension description. En règle générale, la définition de product_short_descriptions remplace simplement la définition de products, car elle 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, il prendra la définition de products et l'insérera là où ${EXTENDED} est utilisé. Dans ce cas, la définition résultante pour description est LEFT(${TABLE}.full_description, 50).

Éléments à prendre en compte

Projets avec localisation

Lorsque vous étendez un objet, gardez à l'esprit 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.