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 "ambiente de execução" é a parte do Looker que interpreta o código do LookML. O novo ambiente de execução é mais rápido e verifica mais erros do LookML do que o ambiente de execução legado.

O Looker recomenda que todos os clientes migrem para o novo ambiente de execução. O novo ambiente de execução do LookML é capaz de detectar erros que antes eram ignorados. Portanto, ativar o novo ambiente de execução pode fazer com que novos erros do LookML apareçam. Esses erros não são causados pelo novo ambiente de execução. Em vez disso, são 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.

Como mudar para o novo ambiente de execução

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

Alguns Lookers estão ativados com o recurso legado Usar o ambiente de execução do LookML legado. 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 do LookML legado não estiver disponível na página de administração Recursos legados da 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 ambiente 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 de fazer a transição para o novo ambiente de execução, você poderá notar novos erros no LookML. Os novos erros não são causados pelo novo ambiente de execução. Em vez disso, são problemas preexistentes que agora estão sendo encontrados.

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 do LookML pode encontrar no seu projeto e como corrigi-los:

Algumas tabelas derivadas persistentes podem ser recriadas

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

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

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

html:
  {{ value |replace("<strong>"), "[" |replace("</strong>"), "]" }} ;;

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, uma sql_distinct_key que faz referência a um campo ou visualização desconhecido vai gerar uma exceção. Por exemplo:

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

A medida de tipo "distinto" sem chave primária produz SQL diferente

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

Especifique uma primary-key ou sql_distinct_key ao criar medidas de tipo distinto.

O acesso a _filters[] no 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 ambiente de execução legado ignorava referências de campo simples quando usadas com a variável líquida do Liquid _filters. O novo ambiente de execução adiciona o campo à cláusula SELECT da 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 legado, _filters[users.created_date] sempre seria ignorado, e apenas a segunda condição de {% if %} seria atendida. No novo ambiente de execução, users.created_date é 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 ser confusa para os usuários. Portanto, a prática recomendada é não usar referências de campo simples e, em vez disso, usar aspas simples ao redor do nome do campo ao usar _filters[] no Liquid. Por exemplo, 'users.created_date'.