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 de LookML. El nuevo entorno de ejecución es más rápido y detecta más errores de LookML que el entorno de ejecución heredado.
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 se pasaban por alto, por lo que habilitarlo puede provocar la aparición de errores nuevos de LookML. Estos errores no se deben al nuevo tiempo de ejecución, sino que son errores preexistentes que ahora se detectan.
Además, los clientes que quieran cambiar su instancia a Looker (Google Cloud Core) deben migrar al nuevo entorno de ejecución de antemano.
Cómo cambiar al nuevo entorno de ejecución
1. Desactiva la función heredada "Usar el tiempo de ejecución de LookML heredado" si está disponible.
Algunos Lookers están habilitados con la función heredada Use Legacy LookML Runtime. Inhabilita la función heredada Use Legacy LookML Runtime para realizar la transición de la instancia de Looker al nuevo entorno de ejecución.
Si la función heredada Use Legacy LookML Runtime no está disponible en la página de administrador Legacy Features de tu instancia de Looker, significa que tu instancia ya está usando el nuevo entorno 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 parámetro de configuración global Use Legacy LookML Runtime de una instancia de Looker agregando la instrucción new_lookml_runtime:no en el 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 que new_lookml_runtime esté configurado como yes en todos los proyectos de LookML.
Problemas de LookML que puede encontrar el nuevo entorno de ejecución
Después de la transición al nuevo entorno de ejecución, es posible que observes errores nuevos en tu LookML. Los errores nuevos no se deben al nuevo tiempo de ejecución, sino que son problemas preexistentes que ahora se detectan.
Según la configuración del desarrollador de LookML, es posible que debas corregir estos errores antes de continuar con el envío de cambios de LookML. En las siguientes secciones, se describen algunos de los problemas que el nuevo entorno de ejecución de LookML puede encontrar en tu proyecto y cómo solucionarlos:
- Es posible que se recompilen algunas tablas derivadas persistentes
- Es posible que los literales HTML dentro de las expresiones de Liquid se conviertan a Unicode
- Las referencias no válidas en los resultados de
sql_distinct_keygeneran el error "vista desconocida" - La medida de tipo distinto sin clave primaria genera un SQL diferente
- Acceder a
_filters[]en Liquid con una referencia de campo simple agregará el campo al que se hace referencia como una columna seleccionada
Es posible que se vuelvan a compilar algunas tablas derivadas persistentes
Las claves de tablas derivadas persistentes (PDT) se basan en el código SQL que genera el tiempo de ejecución de LookML. En algunos casos, el nuevo tiempo de ejecución puede generar un SQL diferente (pero equivalente) para una PDT, lo que genera una clave de PDT diferente. Si se cambia una clave de PDT, se volverá a compilar la PDT.
Es posible que los literales HTML dentro de las expresiones de Liquid se conviertan a Unicode
El nuevo tiempo de ejecución puede convertir las etiquetas HTML en expresiones Liquid a su equivalente en Unicode. Por ejemplo, una etiqueta <strong> se puede convertir en <strong>. En el entorno de ejecución heredado, las etiquetas HTML se podían comparar directamente, como en este ejemplo:
html:
{{ value |replace(""), "[" |replace(""), "]" }} ;;
En el nuevo entorno de ejecución, las comparaciones deben realizarse con Unicode:
html:
{{ value |replace("<strong>"), "[" |replace("</strong>"), "]" }} ;;
Las referencias no válidas en sql_distinct_key generan el error "vista desconocida"
Con el nuevo entorno de ejecución, un sql_distinct_key que haga referencia a un campo o una vista desconocidos arrojará una excepción. Por ejemplo:
measure: total_shipping {
type: sum_distinct
sql: ${order_shipping} ;;
sql_distinct_key: ${some_incorrect_field_name} ;;
}
La medida de tipo "Distinto" sin clave primaria genera un SQL diferente
Una medida de tipo distinto (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) sin el parámetro primary-key o sql_distinct_key puede generar un SQL diferente en el nuevo tiempo de ejecución.
Asegúrate de especificar un primary-key o un sql_distinct_key cuando compiles medidas de tipos distintos.
Acceder a _filters[] en Liquid con una referencia de campo simple agregará el campo al que se hace referencia como una columna seleccionada.
En Looker, una "referencia de campo simple" es aquella que no está encerrada entre llaves, como users.created_date en lugar de ${users.created_date}.
El tiempo de ejecución heredado ignoraba las referencias de campos simples cuando se usaba con la variable _filters de Liquid. El nuevo tiempo de ejecución agregará el campo a la consulta en 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 heredado, _filters[users.created_date] siempre se habría ignorado y solo se habría tenido en cuenta la segunda condición si alguna vez se hubiera cumplido {% if %}. En el nuevo tiempo de ejecución, se agregará users.created_date a la cláusula SELECT de la consulta en 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 simples y, en su lugar, usar la sintaxis ${field_name}.