Migrar para o novo ambiente de execução do LookML

O novo ambiente de execução do LookML está disponível desde o Looker 22.6. Um "tempo de execução" é a parte do Looker que interpreta o código LookML. O novo ambiente de execução é mais rápido e verifica mais erros de LookML do que o ambiente legado.

O Looker recomenda que todos os clientes migrem para o novo ambiente de execução. O novo ambiente de execução do LookML consegue detectar erros que antes passavam despercebidos. Por isso, ativar o novo ambiente pode fazer com que novos erros do LookML apareçam. Esses erros não são causados pelo novo ambiente de execução, mas sim erros preexistentes que agora estão sendo encontrados.

Além disso, os clientes que quiserem mudar a instância para o Looker (Google Cloud Core) precisam migrar para o novo ambiente de execução antes.

Como mudar para o novo ambiente de execução

1. Desative o recurso legado "Usar o tempo de execução do LookML legado", se disponível.

Alguns Looks são ativados com o recurso legado Usar o ambiente de execução da LookML legada. Desative o recurso legado Usar o ambiente de execução do LookML legado para fazer a transição da instância do Looker para o novo ambiente de execução.

Se o recurso legado Usar o ambiente de execução legado da LookML não estiver disponível na página de administrador Recursos legados da sua instância do Looker, ela já estará usando o novo ambiente de execução.

2. Verifique se os projetos do LookML não estão configurados com new_lookml_runtime:no

É possível substituir a configuração global Usar o tempo de execução do LookML legado de uma instância do Looker adicionando a instrução new_lookml_runtime:no no arquivo de manifesto de um projeto do LookML.

Verifique se os arquivos de manifesto do projeto do LookML não têm o parâmetro new_lookml_runtime ou se new_lookml_runtime está definido como yes em todos os projetos do LookML.

Problemas do LookML que o novo ambiente de execução pode encontrar

Depois da transição para o novo ambiente de execução, talvez você note novos erros na LookML. Os novos erros não são causados pelo novo ambiente de execução. Eles são problemas preexistentes que estão sendo encontrados agora.

Dependendo das configurações do desenvolvedor do LookML, talvez seja necessário corrigir esses erros antes de continuar enviando mudanças do LookML. As seções a seguir descrevem alguns dos problemas que o novo ambiente de execução da LookML pode encontrar no seu projeto e como corrigi-los:

Algumas tabelas derivadas persistentes podem ser recriadas

As chaves de tabela derivada persistente (PDT) são baseadas em SQL gerado pelo ambiente de execução do LookML. Em alguns casos, o novo ambiente de execução pode gerar um SQL diferente (mas equivalente) para um PDT, resultando em uma chave de PDT diferente. Uma mudança na chave de uma TDP faz com que ela seja recriada.

Os literais HTML dentro de expressões Liquid podem ser convertidos em Unicode

As tags HTML em expressões Liquid podem ser convertidas para o equivalente Unicode pelo novo tempo de execução. Por exemplo, uma tag <strong> pode ser convertida em &lt;strong&gt;. No ambiente de execução legado, as tags HTML podiam ser comparadas diretamente, como neste exemplo:

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

No novo ambiente de execução, as comparações precisam ser feitas com o Unicode:

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

Referências inválidas em sql_distinct_key resultam em "visualização desconhecida"

Com o novo ambiente de execução, um sql_distinct_key que faz referência a um campo ou uma visualização desconhecida vai gerar uma exceção. Exemplo:

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

A medida do tipo "Distinct" sem chave primária gera um SQL diferente

Uma métrica de tipo distinto (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) sem um parâmetro primary-key ou sql_distinct_key pode gerar um SQL diferente no novo ambiente de execução.

Especifique um primary-key ou sql_distinct_key ao criar medidas de tipo distintas.

Acessar _filters[] em Liquid com uma referência de campo simples adiciona o campo referenciado como uma coluna selecionada.

No Looker, uma "referência de campo simples" é aquela que não está entre chaves, como users.created_date em vez de ${users.created_date}.

O runtime legada ignorava referências de campo simples quando usado com a variável Liquid _filters. O novo ambiente de execução vai adicionar o campo à consulta SQL.

Por exemplo, nesta dimensão, users.created_date é uma referência simples:

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

No ambiente de execução legada, _filters[users.created_date] sempre seria ignorado, e apenas a segunda condição seria atendida se {% if %} fosse atendida. No novo ambiente de execução, users.created_date será adicionado à cláusula SELECT da consulta SQL para que a condição possa ser avaliada.

A adição automática de campos inesperados às consultas do Looker pode confundir os usuários. Por isso, a prática recomendada é não usar referências de campo simples e usar a sintaxe ${field_name}.