Migrazione al nuovo runtime di LookML

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

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

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

Come passare al nuovo runtime

1. Disattiva la funzionalità legacy "Utilizza l'ambiente di runtime LookML legacy", se disponibile

Alcuni Looker sono attivati con la funzionalità precedente Utilizza l'ambiente di runtime LookML precedente. Disattiva la funzionalità precedente Utilizza il runtime LookML precedente per eseguire la transizione dell'istanza di Looker al nuovo runtime.

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

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

È possibile ignorare l'impostazione globale Utilizza l'ambiente di runtime LookML precedente 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 contengano 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 codice LookML. I nuovi errori non sono causati dal nuovo runtime, ma si tratta di problemi preesistenti che ora vengono rilevati.

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

• Alcune tabelle derivate permanenti potrebbero essere ricostruite
• I valori letterali HTML all'interno delle espressioni Liquid possono essere convertiti in Unicode
• Riferimenti non validi in sql_distinct_key generano "Visualizzazione sconosciuta"
• La misura del tipo distinto senza chiave primaria produce SQL diverso
• L'accesso a _filters[] in Liquid con un riferimento a un campo senza nome aggiungerà il campo a cui si fa riferimento come colonna selezionata

Alcune tabelle derivate permanenti potrebbero essere ricostruite

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

I valori letterali HTML all'interno delle espressioni Liquid possono 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 <strong>. Nel runtime precedente, i tag HTML potevano essere confrontati direttamente, come in questo esempio:

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

Nel nuovo runtime, i confronti devono essere effettuati in base al codice Unicode:

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

I riferimenti non validi in sql_distinct_key generano "Visualizzazione sconosciuta"

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

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

La misura di tipo "Disgiunti" senza chiave primaria produce SQL diverso

Una misura di tipo distinto (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) senza parametro primary-key o sql_distinct_key potrebbe produrre 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 a un campo senza nome aggiungerà il campo a cui si fa riferimento come colonna selezionata

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

Il runtime precedente ignorava i riferimenti ai campi non inizializzati 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 nudo:

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ò creare confusione negli utenti, pertanto la best practice è non utilizzare riferimenti ai campi senza nome, ma la sintassi ${field_name}.