Migrar al nuevo entorno de ejecución de LookML

El nuevo tiempo de ejecución de LookML está disponible desde Looker 22.6. Un "tiempo de ejecución" es la parte de Looker que interpreta el código LookML. El nuevo tiempo de ejecución es más rápido y comprueba más errores de LookML que el antiguo.

Looker recomienda encarecidamente a todos los clientes que migren al nuevo tiempo de ejecución. El nuevo tiempo de ejecución de LookML puede detectar errores que antes pasaban desapercibidos, por lo que habilitarlo puede provocar que aparezcan nuevos errores de LookML. Estos errores no se deben al nuevo tiempo de ejecución, sino que son errores que ya existían y que ahora se han detectado.

Además, los clientes que quieran cambiar su instancia a Looker (Google Cloud core) deben migrar al nuevo tiempo de ejecución antes.

Cómo cambiar al nuevo entorno de ejecución

1. Desactiva la función antigua "Usar el tiempo de ejecución de LookML antiguo", si está disponible.

Algunos Looks tienen habilitada la función antigua Usar el tiempo de ejecución de LookML antiguo. Inhabilita la función antigua Usar el tiempo de ejecución de LookML antiguo para migrar la instancia de Looker al nuevo tiempo de ejecución.

Si la función antigua Usar el tiempo de ejecución de LookML antiguo no está disponible en la página de administrador Funciones antiguas de tu instancia de Looker, significa que tu instancia ya está usando el nuevo tiempo de ejecución.

2. Asegúrate de que tus proyectos de LookML no estén configurados con new_lookml_runtime:no.

Es posible anular el ajuste global Usar el tiempo de ejecución de LookML antiguo de una instancia de Looker añadiendo la instrucción new_lookml_runtime:no al archivo de manifiesto de un proyecto de LookML.

Asegúrate de que los archivos de manifiesto de tu proyecto de LookML no tengan el parámetro new_lookml_runtime o de que new_lookml_runtime esté definido como yes en todos los proyectos de LookML.

Problemas de LookML que puede encontrar el nuevo tiempo de ejecución

Después de cambiar al nuevo tiempo de ejecución, es posible que observes nuevos errores en tu LookML. Los nuevos errores no se deben al nuevo tiempo de ejecución, sino que son problemas que ya existían y que ahora se han detectado.

En función de la configuración de desarrollador de LookML, es posible que tengas que corregir estos errores para poder enviar los cambios de LookML. En las siguientes secciones se describen algunos de los problemas que puede encontrar el nuevo tiempo de ejecución de LookML en tu proyecto y cómo solucionarlos:

Es posible que se vuelvan a compilar algunas tablas derivadas persistentes

Las claves de tablas derivadas persistentes (PDTs) se basan en el SQL generado por el tiempo de ejecución de LookML. En algunos casos, el nuevo tiempo de ejecución puede generar un SQL diferente (pero equivalente) para un PDT, lo que da como resultado una clave de PDT diferente. Si se cambia una clave de PDT, se volverá a generar la PDT.

Los literales HTML dentro de expresiones Liquid pueden convertirse a Unicode

Las etiquetas HTML de las expresiones Liquid pueden convertirse en su equivalente Unicode con el nuevo tiempo de ejecución. Por ejemplo, una etiqueta <strong> puede convertirse en &lt;strong&gt;. En el tiempo de ejecución antiguo, las etiquetas HTML se podían comparar directamente, como en este ejemplo:

html:
  {{ value |replace(""), "[" |replace(""), "]" }} ;;

En el nuevo tiempo de ejecución, las comparaciones deben hacerse con Unicode:

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

Las referencias no válidas en sql_distinct_key dan como resultado "vista desconocida"

Con el nuevo tiempo de ejecución, un sql_distinct_key que haga referencia a un campo o una vista desconocidos generará una excepción. Por ejemplo:

measure: total_shipping {
  type: sum_distinct
  sql: ${order_shipping} ;;
  sql_distinct_key: ${some_incorrect_field_name} ;;
}

Las medidas de tipo "Distintas" sin clave principal generan un SQL diferente

Una medida de tipo distinto (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) sin los parámetros primary-key o sql_distinct_key puede generar un SQL diferente en el nuevo tiempo de ejecución.

Asegúrate de especificar primary-key o sql_distinct_key al crear medidas de tipo distinto.

Si se accede a _filters[] en Liquid con una referencia de campo simple, el campo al que se hace referencia se añadirá como columna seleccionada.

En Looker, una "referencia de campo sin formato" es aquella que no está entre llaves, como users.created_date en lugar de ${users.created_date}.

El tiempo de ejecución antiguo ignoraba las referencias de campos sin formato cuando se usaban con la variable de Liquid _filters. El nuevo tiempo de ejecución añadirá el campo a la consulta SQL.

Por ejemplo, en esta dimensión, users.created_date es una referencia simple:

dimension: name {
  html:
    {% if _filters[users.created_date] != NULL %}
      {{rendered_value}} (created: {{_filters[users.created_date]}})
    {% else %}
      {{rendered_value}}
    {% endif %}
    ;;
}

En el tiempo de ejecución antiguo, _filters[users.created_date] siempre se habría ignorado y solo se habría cumplido la segunda condición si se hubiera cumplido {% if %}. En el nuevo tiempo de ejecución, se añadirá users.created_date a la cláusula SELECT de la consulta SQL para que se pueda evaluar la condición.

La adición automática de campos inesperados a las consultas de Looker puede confundir a los usuarios, por lo que la práctica recomendada es no usar referencias de campos sin formato y, en su lugar, usar la sintaxis ${field_name}.