Le nouveau runtime LookML est disponible depuis Looker 22.6. L'environnement d'exécution est la partie de Looker qui interprète le code LookML. Le nouveau runtime est plus rapide et détecte plus d'erreurs LookML que l'ancien.
Looker encourage vivement tous ses clients à migrer vers le nouveau runtime. La nouvelle version du runtime LookML est capable de détecter des erreurs précédemment ignorées. Par conséquent, son activation peut entraîner l'apparition de nouvelles erreurs LookML. Ces erreurs ne sont pas causées par le nouveau runtime. Il s'agit plutôt d'erreurs préexistantes qui sont maintenant détectées.
De plus, les clients qui souhaitent remplacer leur instance par Looker (Google Cloud Core) doivent migrer vers le nouvel environnement d'exécution au préalable.
Passer au nouvel environnement d'exécution
1. Désactivez l'ancienne fonctionnalité "Utiliser l'ancienne version de l'environnement d'exécution LookML", le cas échéant.
Certaines fonctionnalités Looker sont activées avec l'ancienne fonctionnalité Utiliser l'ancienne version de l'exécution LookML. Désactivez la fonctionnalité héritée Utiliser l'ancienne version de l'environnement d'exécution LookML pour passer l'instance Looker à la nouvelle version de l'environnement d'exécution.
Si l'ancienne fonctionnalité Utiliser l'ancien environnement d'exécution LookML n'est pas disponible sur la page d'administration Anciennes fonctionnalités de votre instance Looker, votre instance utilise déjà le nouvel environnement d'exécution.
2. Assurez-vous que vos projets LookML ne sont pas configurés avec new_lookml_runtime:no
Vous pouvez remplacer le paramètre global Use Legacy LookML Runtime (Utiliser l'ancienne version de l'environnement d'exécution LookML) d'une instance Looker en ajoutant l'instruction new_lookml_runtime:no dans le fichier manifeste d'un projet LookML.
Assurez-vous que les fichiers manifestes de vos projets LookML ne contiennent pas le paramètre new_lookml_runtime ou que new_lookml_runtime est défini sur yes dans tous les projets LookML.
Problèmes LookML que le nouvel environnement d'exécution peut détecter
Après la transition vers le nouveau runtime, vous remarquerez peut-être de nouvelles erreurs dans votre LookML. Les nouvelles erreurs ne sont pas causées par le nouveau runtime. Il s'agit plutôt de problèmes préexistants qui sont maintenant détectés.
Selon vos paramètres de développeur LookML, vous devrez peut-être corriger ces erreurs avant de continuer à envoyer des modifications LookML. Les sections suivantes décrivent certains des problèmes que le nouveau runtime LookML peut détecter dans votre projet et comment les résoudre:
- Certaines tables dérivées persistantes peuvent être regénérées
- Les littéraux HTML dans les expressions Liquid peuvent être convertis en Unicode
- Références non valides dans
sql_distinct_key: "vue inconnue" - La mesure de type distinct sans clé primaire produit du code SQL différent
- Accéder à
_filters[]dans Liquid avec une référence de champ brute ajoute le champ référencé en tant que colonne sélectionnée.
Certaines tables dérivées persistantes peuvent être regénérées
Les clés de table dérivée persistante (PDT) sont basées sur le code SQL généré par l'environnement d'exécution LookML. Dans certains cas, le nouveau runtime peut générer du code SQL différent (mais équivalent) pour une table PDT, ce qui entraîne une clé PDT différente. Si vous modifiez une clé de table PDT, la table sera regénérée.
Les littéraux HTML dans les expressions Liquid peuvent être convertis en Unicode
Les balises HTML dans les expressions Liquid peuvent être converties en leur équivalent Unicode par le nouveau runtime. Par exemple, une balise <strong> peut être convertie en <strong>. Dans l'ancien environnement d'exécution, les balises HTML pouvaient être comparées directement, comme dans cet exemple:
html:
{{ value |replace(""), "[" |replace(""), "]" }} ;;
Dans le nouvel environnement d'exécution, les comparaisons doivent être effectuées avec l'unicode:
html:
{{ value |replace("<strong>"), "[" |replace("</strong>"), "]" }} ;;
Références non valides dans sql_distinct_key : "vue inconnue"
Avec le nouveau runtime, un sql_distinct_key qui fait référence à un champ ou à une vue inconnus génère une exception. Exemple :
measure: total_shipping {
type: sum_distinct
sql: ${order_shipping} ;;
sql_distinct_key: ${some_incorrect_field_name} ;;
}
La mesure de type "Distinct" sans clé primaire produit une requête SQL différente
Une mesure de type distincte (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) sans paramètre primary-key ou sql_distinct_key peut produire du code SQL différent dans le nouveau runtime.
Veillez à spécifier un primary-key ou un sql_distinct_key lorsque vous créez des mesures de type distinctes.
Accéder à _filters[] dans Liquid avec une référence de champ brute ajoute le champ référencé en tant que colonne sélectionnée.
Dans Looker, une "référence de champ nue" est une référence qui n'est pas placée entre crochets, par exemple users.created_date au lieu de ${users.created_date}.
L'ancien environnement d'exécution ignorait les références de champ nues lorsqu'elles étaient utilisées avec la variable Liquid _filters. Le nouveau runtime ajoutera le champ à la requête SQL.
Par exemple, dans cette dimension, users.created_date est une référence simple:
dimension: name {
html:
{% if _filters[users.created_date] != NULL %}
{{rendered_value}} (created: {{_filters[users.created_date]}})
{% else %}
{{rendered_value}}
{% endif %}
;;
}
Dans l'ancien environnement d'exécution, _filters[users.created_date] aurait toujours été ignoré et seule la deuxième condition aurait été appliquée si {% if %} avait été remplie. Dans le nouvel environnement d'exécution, users.created_date sera ajouté à la clause SELECT de la requête SQL afin que la condition puisse être évaluée.
L'ajout automatique de champs inattendus aux requêtes Looker peut prêter à confusion pour les utilisateurs. Il est donc recommandé de ne pas utiliser de références de champ brutes, mais plutôt la syntaxe ${field_name}.