Zur neuen LookML-Laufzeit migrieren

Die neue LookML-Laufzeit ist seit Looker 22.6 verfügbar. Eine „Laufzeit“ ist der Teil von Looker, der LookML-Code interpretiert. Die neue Laufzeit ist schneller und prüft auf mehr LookML-Fehler als die alte Laufzeit.

Looker empfiehlt allen Kunden dringend, zur neuen Laufzeit zu migrieren. Mit der neuen LookML-Laufzeit können bisher übersehene Fehler erkannt werden. Wenn Sie die neue Laufzeit aktivieren, können daher neue LookML-Fehler auftreten. Diese Fehler werden nicht durch die neue Laufzeit verursacht, sondern sind bereits vorhanden und werden jetzt gefunden.

Kunden, die ihre Instanz in Looker (Google Cloud Core) ändern möchten, müssen außerdem zuerst zur neuen Laufzeit migrieren.

Zur neuen Laufzeit wechseln

1. Deaktivieren Sie die Legacy-Funktion „Legacy LookML Runtime verwenden“, falls verfügbar.

Einige Looker sind mit dem Legacy-Feature Use Legacy LookML Runtime (Alte LookML-Laufzeit verwenden) aktiviert. Deaktivieren Sie die Legacy-Funktion Legacy LookML Runtime verwenden, um die Looker-Instanz auf die neue Laufzeit umzustellen.

Wenn die Legacy-Funktion Use Legacy LookML Runtime auf der Seite Legacy Features Ihrer Looker-Instanz nicht verfügbar ist, wird auf Ihrer Instanz bereits die neue Laufzeit verwendet.

2. Achten Sie darauf, dass Ihre LookML-Projekte nicht mit new_lookml_runtime:no konfiguriert sind.

Sie können die globale Einstellung Use Legacy LookML Runtime einer Looker-Instanz überschreiben, indem Sie die Anweisung new_lookml_runtime:no in die Manifestdatei eines LookML-Projekts einfügen.

Achten Sie darauf, dass Ihre LookML-Projektmanifestdateien nicht den Parameter new_lookml_runtime enthalten oder dass new_lookml_runtime in allen LookML-Projekten auf yes festgelegt ist.

LookML-Probleme, die von der neuen Laufzeit erkannt werden können

Nach der Umstellung auf die neue Laufzeit können in Ihrem LookML neue Fehler auftreten. Die neuen Fehler werden nicht durch die neue Laufzeitumgebung verursacht, sondern sind bereits vorhandene Probleme, die jetzt gefunden werden.

Je nach Ihren LookML-Entwicklereinstellungen müssen Sie diese Fehler möglicherweise beheben, bevor Sie weitere LookML-Änderungen einreichen können. In den folgenden Abschnitten werden einige der Probleme beschrieben, die die neue LookML-Laufzeit in Ihrem Projekt finden kann, und wie Sie sie beheben können:

Einige persistente abgeleitete Tabellen werden möglicherweise neu erstellt

Schlüssel für persistente abgeleitete Tabellen (PDTs) basieren auf SQL, das von der LookML-Laufzeit generiert wird. In einigen Fällen kann die neue Laufzeit eine andere (aber gleichwertige) SQL-Anweisung für eine PDT generieren, was zu einem anderen PDT-Schlüssel führt. Wenn Sie einen PDT-Schlüssel ändern, wird die PDT neu erstellt.

HTML-Literale in Liquid-Ausdrücken werden möglicherweise in Unicode konvertiert

HTML-Tags in Liquid-Ausdrücken werden von der neuen Laufzeit möglicherweise in ihr Unicode-Äquivalent konvertiert. Ein <strong>-Tag kann beispielsweise in &lt;strong&gt; konvertiert werden. In der Legacy-Laufzeit konnten HTML-Tags direkt verglichen werden, wie in diesem Beispiel:

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

In der neuen Laufzeit müssen Vergleiche stattdessen mit dem Unicode erfolgen:

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

Ungültige Verweise in sql_distinct_key führen zu „unbekannte Ansicht“

In der neuen Laufzeit wird bei einem sql_distinct_key, das auf ein unbekanntes Feld oder eine unbekannte Ansicht verweist, eine Ausnahme ausgelöst. Beispiel:

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

Messwert vom Typ „Distinct“ ohne Primärschlüssel führt zu unterschiedlichem SQL-Code

Ein Messwert vom Typ „Distinct“ (average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct) ohne Parameter primary-key oder sql_distinct_key kann in der neuen Laufzeit zu unterschiedlichem SQL führen.

Geben Sie beim Erstellen von Messwerten für unterschiedliche Typen unbedingt primary-key oder sql_distinct_key an.

Wenn Sie in Liquid mit einem einfachen Feldverweis auf _filters[] zugreifen, wird das referenzierte Feld als ausgewählte Spalte hinzugefügt.

In Looker ist eine „bare field reference“ (einfache Feldreferenz) eine Referenz, die nicht in geschweifte Klammern eingeschlossen ist, z. B. users.created_date anstelle von ${users.created_date}.

In der alten Laufzeit wurden einfache Feldverweise ignoriert, wenn sie mit der Liquid-Variable _filters verwendet wurden. Die neue Laufzeit fügt das Feld der SQL-Abfrage hinzu.

In dieser Dimension ist users.created_date beispielsweise ein einfacher Verweis:

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

In der alten Laufzeitumgebung wurde _filters[users.created_date] immer ignoriert und nur die zweite Bedingung berücksichtigt, wenn {% if %} erfüllt war. In der neuen Laufzeit wird users.created_date der SELECT-Klausel der SQL-Abfrage hinzugefügt, damit die Bedingung ausgewertet werden kann.

Das automatische Hinzufügen unerwarteter Felder zu Looker-Abfragen kann für Nutzer verwirrend sein. Daher ist es am besten, keine einfachen Feldreferenzen zu verwenden, sondern stattdessen die ${field_name}-Syntax.