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

O novo tempo 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 tempo de execução é mais rápido e verifica mais erros do LookML do que o tempo de execução antigo.

O Looker recomenda vivamente que todos os clientes migrem para o novo tempo de execução. O novo tempo de execução do LookML consegue detetar erros anteriormente ignorados, pelo que a ativação do novo tempo de execução pode fazer com que apareçam novos erros do LookML. Estes erros não são causados pelo novo tempo de execução. São erros preexistentes que estão a ser encontrados agora.

Além disso, os clientes que pretendam alterar a respetiva instância para o Looker (Google Cloud core) têm de migrar para o novo tempo de execução antecipadamente.

Como mudar para o novo tempo de execução

1. Desative a funcionalidade antiga "Usar tempo de execução do LookML antigo", se estiver disponível

Alguns Looks estão ativados com a funcionalidade antiga Usar o tempo de execução do LookML antigo. Desative a funcionalidade antiga Usar tempo de execução do LookML antigo para fazer a transição da instância do Looker para o novo tempo de execução.

Se a funcionalidade antiga Usar o tempo de execução do LookML antigo não estiver disponível na página de administração Funcionalidades antigas da sua instância do Looker, significa que a instância já está a usar o novo tempo de execução.

2. Certifique-se de que os seus projetos do LookML não estão configurados com new_lookml_runtime:no

É possível substituir a definição global Usar tempo de execução do LookML antigo de uma instância do Looker adicionando a declaração new_lookml_runtime:no no ficheiro de manifesto de um projeto do LookML.

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

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

Após a transição para o novo tempo de execução, pode reparar em novos erros no seu LookML. Os novos erros não são causados pelo novo tempo de execução. Em vez disso, são problemas preexistentes que estão a ser encontrados agora.

Consoante as suas definições de programador do LookML, pode ter de corrigir estes erros antes de continuar a enviar alterações do LookML. As secções seguintes descrevem alguns dos problemas que o novo tempo de execução do LookML pode encontrar no seu projeto e como os resolver:

Algumas tabelas derivadas persistentes podem ser recompiladas

As chaves da tabela derivada persistente (PDT) baseiam-se no SQL gerado pelo tempo de execução do LookML. Em alguns casos, o novo tempo de execução pode gerar um SQL diferente (mas equivalente) para um PDT, o que resulta numa chave de PDT diferente. Uma alteração de uma chave de PDT faz com que a PDT seja recompilada.

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

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

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

No novo tempo de execução, as comparações têm de ser feitas com o Unicode:

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

As referências inválidas em sql_distinct_key resultam em "vista desconhecida"

Com o novo tempo de execução, um sql_distinct_key que faça referência a um campo ou uma vista desconhecidos 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 do tipo "Distinta" sem chave primária produz um SQL diferente

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

Certifique-se de que especifica um primary-key ou sql_distinct_key quando criar medidas de tipo distintas.

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" é uma referência que não está entre chavetas, como users.created_date em vez de ${users.created_date}.

O tempo de execução antigo ignorava as referências de campos simples quando usadas com a _filters variável Liquid. O novo tempo de execução adiciona 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 tempo de execução antigo, _filters[users.created_date] teria sido sempre ignorado e apenas a segunda condição teria sido cumprida se {% if %} tivesse sido cumprido. No novo tempo 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 a consultas do Looker pode confundir os utilizadores. Por isso, a prática recomendada é não usar referências de campos simples e, em vez disso, usar a sintaxe ${field_name}.