El nuevo entorno de ejecución de LookML está disponible desde Looker 22.6. Un "entorno 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 a todos los clientes que migren al nuevo entorno de ejecución. El nuevo entorno de ejecución de LookML puede detectar errores que se pasaron por alto anteriormente, por lo que habilitar el nuevo entorno de ejecución puede hacer que aparezcan nuevos errores de LookML. Estos errores no son causados por el nuevo entorno de ejecución, sino que son errores preexistentes que ahora se encuentran.
Además, los clientes que quieran cambiar su instancia a Looker (Google Cloud Core) deben migrar al nuevo entorno de ejecución con anticipación.
Cómo cambiar al nuevo entorno de ejecución
1. Si está disponible, desactiva la función heredada "Usar entorno de ejecución de LookML heredado".
Algunos objetos Looker están habilitados con la función heredada Use Legacy LookML Runtime. Inhabilita la función heredada Use Legacy LookML Runtime para migrar 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 administración Legacy Features de tu instancia de Looker, significa que tu instancia ya usa el entorno de ejecución nuevo.
2. Asegúrate de que tus proyectos de LookML no estén configurados con new_lookml_runtime:no
Para anular el parámetro de configuración global Use Legacy LookML Runtime de una instancia de Looker, agrega la sentencia 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 de 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 notes errores nuevos en tu código LookML. Los errores nuevos no son causados por el nuevo entorno de ejecución, sino que son problemas preexistentes que ahora se están encontrando.
Según la configuración de desarrollador de LookML, es posible que debas corregir estos errores antes de seguir enviando 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 vuelvan a crear algunas tablas derivadas persistentes
- Los literales HTML dentro de las expresiones de Liquid se pueden convertir a Unicode
- Las referencias no válidas en
sql_distinct_keygeneran una "vista desconocida". - La medida de tipo distinto sin clave primaria produce SQL diferente
- Si accedes a
_filters[]en Liquid con una referencia de campo sin formato, se agregará el campo de referencia como una columna seleccionada.
Es posible que se vuelvan a compilar algunas tablas derivadas persistentes
Las claves de las tablas derivadas persistentes (PDT) se basan en el SQL que genera el entorno de ejecución de LookML. En algunos casos, el nuevo entorno de ejecución puede generar SQL diferente (pero equivalente) para un PDT, lo que genera una clave de PDT diferente. Si cambias una clave de PDT, se volverá a compilar.
Los literales HTML dentro de las expresiones de Liquid se pueden convertir a Unicode.
Es posible que el nuevo entorno de ejecución convierta las etiquetas HTML en su equivalente Unicode. Por ejemplo, una etiqueta <strong> puede convertirse 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 muestran el mensaje "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 produce SQL diferente
Una medida de tipo distinta (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) sin el parámetro primary-key o sql_distinct_key puede producir SQL diferente en el nuevo entorno de ejecución.
Asegúrate de especificar un primary-key o un sql_distinct_key cuando crees medidas de tipo distintas.
Si accedes a _filters[] en Liquid con una referencia de campo sin formato, se agregará el campo de referencia como una columna seleccionada.
En Looker, una "referencia de campo sin formato" es aquella que no está encerrada entre llaves, como users.created_date en lugar de ${users.created_date}.
El entorno de ejecución heredado ignoraba las referencias de campo sin formato cuando se usaba con la variable de Liquid _filters. El nuevo entorno de ejecución agregará el campo a la consulta de SQL.
Por ejemplo, en esta dimensión, users.created_date es una referencia sin formato:
dimension: name {
html:
{% if _filters[users.created_date] != NULL %}
{{rendered_value}} (created: {{_filters[users.created_date]}})
{% else %}
{{rendered_value}}
{% endif %}
;;
}
En el entorno de ejecución heredado, siempre se habría ignorado _filters[users.created_date] y solo se habría cumplido la segunda condición si se hubiera cumplido {% if %}. En el nuevo entorno de ejecución, users.created_date se agregará 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 ser confusa para los usuarios, por lo que se recomienda no usar referencias de campos sin formato y, en su lugar, usar la sintaxis ${field_name}.