Migrer vers le nouvel environnement d'exécution LookML

Le nouveau runtime LookML est disponible depuis Looker 22.6. Un "runtime" 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 les clients à migrer vers le nouveau runtime. Le nouveau runtime LookML est capable de détecter des erreurs qui étaient auparavant ignorées. Par conséquent, l'activation du nouveau runtime peut entraîner l'apparition de nouvelles erreurs LookML. Ces erreurs ne sont pas causées par le nouveau runtime. Il s'agit d'erreurs préexistantes qui sont désormais détectées.

De plus, les clients qui souhaitent passer à Looker (Google Cloud Core) doivent d'abord migrer vers le nouvel environnement d'exécution.

Passer au nouvel environnement d'exécution

1. Désactivez l'ancienne fonctionnalité "Utiliser l'ancien moteur d'exécution LookML", si elle est disponible.

Certaines instances Looker sont activées avec l'ancienne fonctionnalité Utiliser l'ancien LookML Runtime. Désactivez l'ancienne fonctionnalité Utiliser l'ancien environnement d'exécution LookML pour faire passer l'instance Looker au nouvel 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, cela signifie que 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.

Il est possible de remplacer le paramètre global Utiliser l'ancien moteur 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 votre projet 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 désormais détectés.

Selon vos paramètres de développeur LookML, vous devrez peut-être corriger ces erreurs avant de pouvoir continuer à envoyer des modifications LookML. Les sections suivantes décrivent certains des problèmes que le nouveau moteur d'exécution LookML peut détecter dans votre projet et comment les résoudre :

Certaines tables dérivées persistantes peuvent être reconstruites

Les clés des tables dérivées persistantes (PDT) sont basées sur le code SQL généré par le moteur d'exécution LookML. Dans certains cas, le nouveau runtime peut générer un code SQL différent (mais équivalent) pour une PDT, ce qui entraîne une clé PDT différente. Si vous modifiez la clé d'une PDT, celle-ci sera régé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 moteur d'exécution. Par exemple, un tag <strong> peut être converti en &lt;strong&gt;. 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 par rapport à l'Unicode :

html:
  {{ value |replace("&lt;strong&gt;"), "[" |replace("&lt;/strong&gt;"), "]" }} ;;

Références non valides dans les résultats sql_distinct_key entraînant l'affichage de "vue inconnue"

Avec le nouveau runtime, un sql_distinct_key qui fait référence à un champ ou une vue inconnus générera 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 génère un code SQL différent.

Une mesure de type distinct (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) sans paramètre primary-key ni sql_distinct_key peut générer un code SQL différent dans le nouveau moteur d'exécution.

Veillez à spécifier primary-key ou sql_distinct_key lorsque vous créez des mesures de type distinct.

L'accès à _filters[] dans Liquid avec une référence de champ nue ajoutera 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 accolades, comme users.created_date au lieu de ${users.created_date}.

L'ancien moteur d'exécution ignorait les références de champ brutes lorsqu'il était utilisé avec la variable Liquid _filters. Le nouveau moteur d'exécution ajoutera le champ à la requête SQL.

Par exemple, dans cette dimension, users.created_date est une référence brute :

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é remplie si {% if %} avait été respecté. Dans le nouveau runtime, 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 dérouter les utilisateurs. Il est donc recommandé de ne pas utiliser de références de champ brutes et d'utiliser plutôt la syntaxe ${field_name}.