Migrazione al nuovo runtime di LookML

Il nuovo runtime LookML è disponibile a partire da Looker 22.6. Un "runtime" è la parte di Looker che interpreta il codice LookML. Il nuovo runtime è più veloce e controlla più errori di LookML rispetto al runtime precedente.

Looker consiglia vivamente a tutti i clienti di eseguire la migrazione al nuovo runtime. Il nuovo runtime LookML è in grado di rilevare errori precedentemente trascurati, pertanto l'attivazione del nuovo runtime potrebbe causare la visualizzazione di nuovi errori LookML. Questi errori non sono causati dal nuovo runtime, ma sono errori preesistenti che ora vengono rilevati.

Inoltre, i clienti che vogliono passare a Looker (Google Cloud core) devono eseguire la migrazione al nuovo runtime in anticipo.

Come passare al nuovo runtime

1. Disattiva la funzionalità legacy "Usa runtime LookML legacy", se disponibile

Alcuni look sono abilitati con la funzionalità legacy Utilizza runtime LookML legacy. Disattiva la funzionalità legacy Utilizza il runtime LookML legacy per eseguire la transizione dell'istanza Looker al nuovo runtime.

Se la funzionalità legacy Utilizza runtime LookML legacy non è disponibile nella pagina di amministrazione Funzionalità legacy della tua istanza di Looker, significa che la tua istanza utilizza già il nuovo runtime.

2. Assicurati che i tuoi progetti LookML non siano configurati con new_lookml_runtime:no

È possibile ignorare l'impostazione globale Utilizza runtime LookML legacy di un'istanza di Looker aggiungendo l'istruzione new_lookml_runtime:no nel file manifest di un progetto LookML.

Assicurati che i file manifest del progetto LookML non abbiano il parametro new_lookml_runtime o che new_lookml_runtime sia impostato su yes in tutti i progetti LookML.

Problemi di LookML che il nuovo runtime potrebbe rilevare

Dopo la transizione al nuovo runtime, potresti notare nuovi errori nel tuo LookML. I nuovi errori non sono causati dal nuovo runtime, ma sono problemi preesistenti che vengono rilevati ora.

A seconda delle impostazioni dello sviluppatore LookML, potrebbe essere necessario correggere questi errori prima di continuare a inviare le modifiche a LookML. Le sezioni seguenti descrivono alcuni dei problemi che il nuovo runtime LookML potrebbe rilevare nel tuo progetto e come risolverli:

Alcune tabelle derivate permanenti potrebbero essere ricostruite

Le chiavi delle tabelle derivate permanenti (PDT) si basano sul codice SQL generato dal runtime LookML. In alcuni casi, il nuovo runtime potrebbe generare un SQL diverso (ma equivalente) per un PDT, con conseguente chiave PDT diversa. La modifica di una chiave PDT comporta la rigenerazione della PDT.

I valori letterali HTML all'interno delle espressioni Liquid potrebbero essere convertiti in Unicode

I tag HTML nelle espressioni Liquid potrebbero essere convertiti nel loro equivalente Unicode dal nuovo runtime. Ad esempio, un tag <strong> potrebbe essere convertito in &lt;strong&gt;. Nel runtime precedente, i tag HTML potevano essere confrontati direttamente, come in questo esempio:

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

Nei nuovi runtime, i confronti devono essere eseguiti con Unicode:

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

Riferimenti non validi in sql_distinct_key comportano la visualizzazione di "visualizzazione sconosciuta"

Con il nuovo runtime, un sql_distinct_key che fa riferimento a un campo o a una visualizzazione sconosciuti genererà un'eccezione. Ad esempio:

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

La misura di tipo "Distinct" senza chiave primaria produce un SQL diverso

Una misura di tipo distinto (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) senza parametri primary-key o sql_distinct_key potrebbe produrre un SQL diverso nel nuovo runtime.

Assicurati di specificare un primary-key o un sql_distinct_key quando crei misure di tipo distinto.

L'accesso a _filters[] in Liquid con un riferimento di campo semplice aggiungerà il campo a cui viene fatto riferimento come colonna selezionata

In Looker, un "riferimento di campo semplice" è un riferimento non racchiuso tra parentesi graffe, ad esempio users.created_date anziché ${users.created_date}.

Il runtime precedente ignorava i riferimenti ai campi semplici se utilizzati con la variabile Liquid _filters. Il nuovo runtime aggiungerà il campo alla query SQL.

Ad esempio, in questa dimensione users.created_date è un riferimento semplice:

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

Nel runtime precedente, _filters[users.created_date] sarebbe sempre stato ignorato e solo la seconda condizione se {% if %} fosse mai stata soddisfatta. Nel nuovo runtime, users.created_date verrà aggiunto alla clausola SELECT della query SQL in modo che la condizione possa essere valutata.

L'aggiunta automatica di campi imprevisti alle query di Looker può confondere gli utenti, pertanto la best practice consiste nel non utilizzare riferimenti di campi semplici e utilizzare invece la sintassi ${field_name}.