Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

Referenz für Flüssigkeitsvariablen

Liquid ist eine Vorlage für Vorlagen, mit der Sie in Looker dynamischere Inhalte erstellen können. So könnten Sie beispielsweise URLs zu externen Tools auf der Grundlage der Ergebnisse einer Abfrage erstellen oder die Datenbanktabelle ändern, die auf der Auswahl eines Nutzers abgefragt wird.

Flüssigkeitsanweisungen werden aus Variablen, Filtern und Tags erstellt. Variablen enthalten Informationen, die Sie verwenden möchten. Die von Looker bereitgestellten Variablen werden auf dieser Seite beschrieben. Du kannst diese Werte mithilfe von Filtern und Tags weiter ändern, über die du in diesem Leitfaden für Flüssigkeiten informierst.

In LookML gibt es mehrere Stellen, an denen Sie Liquid verwenden können:

Den action-Parameter
Der description-Parameter eines Felds (aber nicht für eine explorative Datenanalyse)
Den html-Parameter
Labelparameter auf Feldebene, einschließlich der Parameter label, view_label, group_label und group_item_label
Den link-Parameter
Parameter, die mit sql beginnen, z. B. sql und sql_on
Der Dashboard-Filterparameter default_value
Dashboard-Elementparameter filters

Liquid-Variablen verwenden

Die grundlegende Verwendung von Flüssigkeitsvariablen ist ganz einfach. Wenn Sie die gewünschte Variable ermittelt haben (siehe Liste unten), können Sie sie einfach in einen gültigen LookML-Parameter einfügen. Als Nächstes werden die Flüssigkeitsvariablen definiert, die Sie in bestimmten LookML-Parametern verwenden können.

Zwei Arten der Verwendung von Flüssigkeiten

Es gibt zwei Möglichkeiten, eine Liquid-Variable zu verwenden:

Ausgabesyntax: Diese Art der Nutzung kann Text einfügen und ist die gängigste Methode, um Flüssigkeit in Looker zu verwenden. Bei dieser Methode setzen Sie die Liquid-Variable in zwei geschweifte Klammern. Beispiel: {{ value }}
Tag-Syntax: Diese Art der Verwendung fügt in der Regel keinen Text ein, sondern dient für logische Vergleiche und andere flüssige Vorgänge. Bei dieser Methode schließen Sie die Liquid-Variable in eine geschweifte Klammer und ein einzelnes Prozentzeichen ein. Beispiel: {% dynamic if value > 10000 %}

Einfache Beispiele

In diesem Beispiel der HTML-Nutzung wird eine Produkt-ID in ein <img>-Tag eingefügt, um Produktbilder zu generieren:

dimension: product_image {
  sql: ${product_id} ;;
  html: <img src="https://www.altostrat.com/product_images/{{ value }}.jpg" /> ;;
}

In diesem Beispiel der URL-Nutzung wird ein Künstlername in eine URL eingefügt, um eine Google-Suche für diesen Künstler zu ermöglichen.

dimension: artist_name {
  sql: ${TABLE}.artist_name ;;
  link: {
    label: "Google"
    url: "https://www.google.com/search?q={{ value }}"
    icon_url: "https://google.com/favicon.ico"
  }
}

In diesem Beispiel für eine SQL-Nutzung wird die Datenbanktabelle anhand der Felder festgelegt, die der Nutzer auswählt. Die Syntax verwendet eine if, andernfalls elsif-Struktur, else, um die in der Abfrage enthaltenen Felder zu prüfen und auf sie zu reagieren.

sql_table_name:
  {% dynamic if event.created_date._in_query %}
    event_by_day
  {% elsif event.created_week._in_query %}
    event_by_week
  {% dynamic else %}
    event
  {% dynamic endif %} ;;

In diesem Beispiel für die Labelnutzung ändert die Dimension email den Wert label je nach LookML-Modellname. Dadurch wird dynamisch der Name des Felds in der Feldauswahl und in allen Abfrageergebnissen geändert, die die Dimension email enthalten:

dimension: email {
  label: "{% dynamic if _model._name == 'thelook' %} Looker Registered Email Address {% dynamic else %} External Email Address {% dynamic endif %}"
  type: string
  sql: ${TABLE}.email ;;
}

Weitere Anwendungsbeispiele finden Sie auf der Seite mit den einzelnen LookML-Parametern.

Variablen aus anderen Feldern aufrufen

Flüssigkeitsvariablen basieren in der Regel auf dem Feld, in dem sie verwendet werden. Bei Bedarf können Sie aber auch auf Werte in anderen Feldern zugreifen.

Verwenden Sie das Format {{ view_name.field_name._liquid-variable-name }}, um auf andere Felder aus derselben Zeile im Abfrageergebnis zuzugreifen. Ersetzen Sie _liquid-variable-name durch eine der Looker Liquid-Variablen. Stellen Sie vor, dass dem Variablennamen ein Unterstrich vorangestellt wird, falls er nicht normalerweise so ist:

{{ view_name.field_name._value }}
{{ view_name.field_name._rendered_value }}
{{ view_name.field_name._model._name }}

Dieses Beispiel zeigt, wie Sie über ein anderes Feld auf eine Website-URL zugreifen:

dimension: linked_name {
  sql: ${name} ;;
  html: <a href="{{ website.url._value }}" target="_blank">{{ value }}</a> ;;
}

Wenn Sie auf ein anderes Feld mit der Syntax der Flüssigkeitsvariablen {{ field_name._value }} verweisen, wird das referenzierte Feld der SELECT-Klausel der SQL-Abfrage und als zusätzliche Spalte in der GROUP BY-Klausel hinzugefügt. Nur so können die Werte im referenzierten Feld richtig abgerufen werden. Dies kann jedoch zu unerwarteten Ergebnissen bei den aggregierten Messwerten führen. Weitere Informationen finden Sie im Abschnitt zur Verwendung von Flüssigkeitsvariablen in aggregierten Messwerten auf dieser Seite.

Definitionen von Flüssigkeitsvariablen

In der folgenden Tabelle werden die Flüssigkeitsvariablen beschrieben, die Sie mit LookML verwenden können. Die Spalte Nutzung gibt an, mit welchen LookML-Parametern jede Flüssigkeitsvariable verwendet werden kann. Sie enthält die folgenden Optionen:

A = Funktioniert mit dem Parameter action.

DV = Funktioniert mit dem Parameter default_value (für Dashboards)

DE = Funktioniert mit dem Parameter description auf Feldebene, aber nicht mit description auf der Ebene „Erkunden“.

F = Funktioniert mit dem Parameter filters (für Dashboard-Elemente)

H = Funktioniert mit dem Parameter html.

LA = Funktioniert mit Labelparametern auf Feldebene, einschließlich der Parameter label, view_label, group_label und group_item_label, aber nicht mit Labelparametern auf Modell-, explorativer, Datenansichts- oder Referenzebene oder mit label als Unterparameter von link.

LI = Funktioniert mit dem Parameter link.

S = Funktioniert mit allen LookML-Parametern, die mit sql beginnen (z.B. sql, sql_on und sql_table_name).

Variable	Definition	Nutzung	Beispielausgabe
Feldwerte
`value`	Der Rohwert des Felds, das von der Datenbankabfrage zurückgegeben wird. Kann auf den Wert eines Pivot-Felds verweisen. Zusätzlich zu den Parametern in der Spalte Nutzung wird `value` im Unterparameter `label` der Parameter `action` und `link` unterstützt.	A H LI	8521935
`rendered_value`	Der Wert des Felds mit der Standardformatierung von Looker. Auf der Syntax zur Datumsformatierung in `rendered_value` finden Sie diese Informationen auf der Seite Einfache Datumsformatierung mit Liquid Best Pratices. Zusätzlich zu den in der Spalte Nutzung angezeigten Parametern wird `rendered_value` im Unterparameter `label` der Parameter `action` und `link` unterstützt.	A H LI	8.521.935,00 $
`filterable_value`	Der Wert des Felds, das zur Verwendung als Filter in einer Looker-URL formatiert wurde. Wenn Sie beispielsweise nach einem Stringwert filtern, der ein Komma enthält, z. B. „Altostrat, Inc“, gibt die Variable `value` zwei verschiedene Strings zurück: „Altostrat“ und „Inc“. Die Variable `filterable_value` korrigiert dieses Zeichen, indem Sonderzeichen maskiert werden und ein einzelner String zurückgegeben wird, in diesem Beispiel „Altostrat, Inc“.	A H LI	8521935
Links
`link`	Die URL zum Standard-Aufschlüsselungslink von Looker. Einige Felder haben keinen Standardlink.	A H LI S	/explore/thelook/orders?fields=orders.order_amount&limit=500
`linked_value`	Der Wert des Felds mit der Standardformatierung und der Standardverknüpfung von Looker. Da Messungen keine Standardverknüpfung haben, muss für Messungen der Parameter `drill_fields` konfiguriert werden, damit sie mit `linked_value` funktioniert.	A H LI	8.521.935,00$
Filter
`_filters['view_name.field_name']`	Die Nutzerfilter, die auf das von Ihnen angeforderte Feld angewendet werden, werden mit `view_name.field_name` angegeben. `_filters['view_name.field_name']` wird auch im Parameter `sql` einer abgeleiteten Tabelle unterstützt, in anderen `sql`-Parametern jedoch nicht. Wenn Sie `_filters['view_name.field_name']` in einem abgeleiteten `sql`-Parameter für die Tabelle verwenden möchten, muss der Flüssigkeitsfilter `sql_quote` verwendet werden.	A DE H LA LI	NICHT NULL
`{% date_start date_filter_name %}`	Das Startdatum in einem Datumsfilter, nach dem Sie mit `date_filter_name` fragen. Weitere Informationen finden Sie im Abschnitt Nutzung von `date_start` und `date_end`.	S	2017-01-01
`{% date_end date_filter_name %}`	Das Enddatum in einem Datumsfilter, nach dem Sie mit `date_filter_name` fragen. Weitere Informationen finden Sie im Abschnitt Nutzung von `date_start` und `date_end`.	S	2017-01-01
`{% condition filter_name %}` `sql_or_lookml_reference` `{% endcondition %}`	Der Wert des Filters, den Sie mit `filter_name` anfordern, wird auf `sql_or_lookml_reference` als SQL angewendet. Diese Variable wird mit Vorlagen und bedingten Joins verwendet.	S	Weitere Informationen finden Sie auf der Seite mit den `sql_on`-Dokumentationen für die `sql_on`-Dokumentation auf der Seite mit den bedingten Filtern und dem Abschnitt Bedingte Joins.
`{% parameter parameter_name %}`	Der Wert des Parameterfilters, den Sie mit `parameter_name` abrufen.	DE LA S	Beispiele finden Sie auf der Seite zu `parameter`-Parametern.
`parameter_name._parameter_value`	Injektion des Werts des von Ihnen angeforderten Parameterfilters mit `parameter_name` in eine logische Anweisung	DE H LA LI S	Wichtige Details und Beispiele finden Sie auf der Dokumentationsseite zu `parameter`-Parametern.
Nutzerattribute
`_user_attributes['name_of_attribute']`	Der Wert des Nutzerattributs, den Sie mit `name_of_attribute` für den bestimmten Nutzer angeben, der die Abfrage ausführt, wenn Nutzerattribute verwendet werden. Die Variable `_user_attributes['name_of_attribute']` kann auch in der erweiterten Filtersyntax verwendet werden.	A DE H LA LI S DV F	Nordosten (wenn das Nutzerattribut z. B. „Region“ war) Weitere Informationen finden Sie in den Best Practices auf der Seite Nutzerattribute für das dynamische Schema und den Tabellennamen einfügen.
`_localization['localization_key']`	Gibt den Wert zurück, der mit einem Lokalisierungsschlüssel verknüpft ist, der in der Stringdatei eines Modells basierend auf der Sprache des Nutzers definiert ist.	DV F	Weitere Informationen finden Sie auf der Dokumentationsseite zum Lokalisieren des LookML-Modells.
LookML-Objekte
`_model._name`	Der Name des Modells für dieses Feld.	A DE H LA LI S	der Look
`_view._name`	Der Name der Ansicht für dieses Feld.	A DE H LA LI S	orders
`_explore._name`	Der Name des Felds „Erkunden“ für dieses Feld.	A DE H LA LI S	order_items
`_explore._dashboard_url`	22.12. Die relative URL für das aktuelle Dashboard.	H LI S	/dashboards/5
`_field._name`	Der Name des Felds im Format `view_name.field_name`.	A DE H LA LI S	Bestellungen.Gesamtbestellwert
Abfragen
`_query._query_timezone`	Die Zeitzone, in der die Abfrage ausgeführt wurde.	A DE H LA LI S	Amerika/Los_Angeles
`view_name._in_query`	Gibt `true` zurück, wenn ein Feld aus der Ansicht in der Abfrage enthalten ist.	DE LA LI S	wahr
`view_name.field_name._in_query`	Gibt `true` zurück, wenn das Feld, das mit `view_name.field_name` abgefragt wird, in der Abfragedatentabelle enthalten ist, in einem Filter für eine Abfrage enthalten ist oder in einer Abfrage über den Parameter `required_fields` enthalten ist.	DE LA LI S	wahr
`view_name.field_name._is_selected`	Gibt `true` zurück, wenn das Feld, nach dem Sie mit `view_name.field_name` fragen, in der Abfragedatentabelle angezeigt wird.	DE LA LI S	wahr
`view_name.field_name._is_filtered`	Gibt `true` zurück, wenn das Feld, das mit `view_name.field_name` abgefragt wird, in einem Filter für die Abfrage enthalten ist.	DE LA LI S	wahr

Nutzung von `date_start` und `date_end`

Die Flüssigkeitsvariablen date_start und date_end sind sehr nützlich für Datenbankdialekte, mit denen Daten nach Datum in mehrere Tabellen partitioniert werden, z. B. in BigQuery. Hierfür muss die Tag-Syntax {% date_start date_filter_name %} oder {% date_end date_filter_name %} verwendet werden. Die Ausgabesyntax {{ date_start date_filter_name }} oder {{ date_end date_filter_name }} kann nicht verwendet werden, auch wenn diese Syntax in der Regel zum Generieren von Text genutzt wird.

Sie können diese Felder beispielsweise in einer Ansicht erstellen:


filter: new_filter_test{
  type: date
}

dimension: filter_start{
  type: date
  sql: {% date_start new_filter_test %} ;;
}

dimension: filter_end{
  type: date
  sql: {% date_end new_filter_test %} ;;
}

Wenn Sie ein Explore auf new_filter_test mit dem Zeitraum vom 1. April 2022 bis 25. Mai 2022 filtern, wird die Dimension filter_start mit dem 1. April 2022 ausgewertet und mit filter_end den 25. Mai 2022.

Hinweise zu date_start und date_end:

Wenn der Nutzer die Abfrage nicht mit dem Filter filtert, der im date_filter-Teil der Liquid-Variable angegeben ist, werden sowohl {% date_start date_filter %} als auch {% date_end date_filter %} als NULL ausgewertet.
Wenn der Nutzer die Abfrage mit einem offenen Bereich des Filters filtert, der im date_filter-Teil der Liquid-Variable angegeben ist, wird das offene Ende des Bereichs in NULL aufgelöst. Wenn Sie beispielsweise mit dem Beispiel in der explorativen Datenanalyse den Zeitraum new_filter_testauf vor 2022-06-07 setzen, wird die Ausgabe{% date_start date_filter %} Wenn ein Nutzer new_filter_test auf nach dem 07.06.2022 setzt, ist die Ausgabe {% date_end date_filter %} NULL.

In jedem dieser Szenarien, in denen die flüssige Ausgabe ein Ergebnis von NULL anzeigen kann, müssen Sie eine SQL-Funktion in den sql-Parameter aufnehmen, um NULL-Werte wie IFNULL oder COALESCE zu berücksichtigen, je nach Datenbankdialekt.

Auf der Seite Best Practices für date_start und date_end finden Sie eine ausführliche Erläuterung dazu, wie Sie die Flüssigkeitsvariablen date_start und date_end für Tabellen mit datumspartitionierten Tabellen verwenden.

Ein Beispiel für die Verwendung von date_start und date_end für den flexiblen Zeitraumvergleich finden Sie im Analytics-Block Flexible Analyse im Zeitraumvergleich.

Nutzung von `_in_query`, `_is_selected` und `_is_filtered`

Die Variablen _in_query, _is_selected und _is_filtered geben den Wert „wahr“ oder „falsch“ an, wie in diesem Beispiel gezeigt. Daher ist es wichtig, den richtigen Typ der Referenz für Flüssigkeitsvariablen zu wählen.

Wenn Sie herausfinden möchten, ob etwas in Ihrer Abfrage enthalten ist, und dann bestimmten Text darauf stützen, sollten Sie ein Muster wie dieses verwenden:

{% dynamic if view_name.field_name._in_query %}
  something to insert if true
{% dynamic else %}
  something to insert if false
{% dynamic endif %}

Wenn Sie das Wort „wahr“ oder „falsch“ buchstäblich einfügen möchten, verwenden Sie ein Muster wie das folgende:

{{ view_name.field_name._in_query }}

Einige SQL-Dialekte unterstützen die Literalwörter „true“ und „false“ nicht. In diesem Fall können Sie den Filter sql_boolean hinzufügen, um die benötigten richtigen und falschen Werte zu erhalten:

{{ view_name.field_name._in_query | sql_boolean }}

Für die Variablen _is_selected und _is_filtered gelten dieselben Muster.

Verwendung von Flüssigkeitsvariablen mit dem Parameter `label`

Sie können Flüssigkeitsvariablen im label-Parameter eines Felds verwenden, um das Erscheinungsbild des Felds in der Feldauswahl und in Visualisierungen dynamisch zu ändern. Im Abschnitt Tabelle auf dieser Seite sehen Sie, welche flüssigen Variablen mit dem Parameter label funktionieren.

Flüssigkeitsvariablen funktionieren mit Labelparametern auf Feldebene, einschließlich des Parameters label, des view_label-Parameters, des group_label-Parameters und des group_item_label-Parameters. Sie funktionieren jedoch nicht mit Labelparametern auf der Ebene des Modells, des explorativen Analysetools, der Ansicht oder der Referenzlinie oder mit dem Label als Unterparameter von link.

Die folgenden Variablen können mit label verwendet werden, um die Feldauswahl, die Spaltenüberschriften im Datenbereich einer explorativen Datenanalyse und Visualisierungen zu beeinflussen:

_model._name
_view._name
_explore._name
_field._name
_user_attributes['name_of_attribute']

Die anderen Liquid-Variablen, die in der Tabelle oben mit LA gekennzeichnet sind, z. B. solche, die einen Wert auf der Grundlage eines Filters zurückgeben (z. B. _filters) oder eine Abfrage ausführen, bevor der Variablenwert ermittelt werden kann (z. B. in_query), ändern den Namen des Feldes in der Feldauswahl nicht. In diesen Fällen wird der Feldname nur in der resultierenden Visualisierung geändert.

Wenn Sie die Liquid-Variable parameter mit label verwenden, wird an label der Wert des Unterparameters value übergeben.

Verwendung von Flüssigkeitsvariablen mit dem Parameter `description`

Sie können Flüssigkeitsvariablen mit dem Parameter description verwenden, um die Beschreibung für ein Feld dynamisch zu ändern. Diese Beschreibung wird angezeigt, wenn Nutzer den Mauszeiger auf das Informationssymbol des Felds in der Feldauswahl bewegen, den Spaltennamen im Feld „Daten“ unter „Erkunden“ oder den Spaltennamen in einem Tabellendiagramm. Der Tabelle im Abschnitt Definitionen für Flüssigkeitsvariablen auf dieser Seite können Sie entnehmen, welche flüssigen Variablen mit dem Parameter description funktionieren.

Flüssigkeitsvariablen funktionieren nur mit dem Parameter description auf Feldebene. Sie funktionieren nicht mit dem Parameter description auf der Ebene „Erkunden“.

Mit description können die folgenden Variablen verwendet werden, um die Feldauswahl, den Datenbereich einer explorativen Datenanalyse und die Spaltenüberschrift in einem Tabellendiagramm zu beeinflussen:

_model._name
_view._name
_explore._name
_field._name
_user_attributes['name_of_attribute']

Die anderen Liquid-Variablen, die in der Tabelle oben mit DE gekennzeichnet sind, z. B. Liquid-Variablen, die einen Wert auf der Grundlage eines Filters zurückgeben (z. B. _filters) oder erfordern, dass eine Abfrage ausgeführt werden kann, bevor der Variablenwert ermittelt werden kann (z. B. in_query), ändert die Beschreibung in der Feldauswahl oder im Datenbereich einer explorativen Datenanalyse nicht. Diese Flüssigkeitsvariablen wirken sich nur auf die Beschreibung aus, wenn ein Nutzer in einem Tabellendiagramm den Mauszeiger auf die Spaltenüberschrift bewegt.

Beispiele für die Verwendung von Liquid im Parameter description finden Sie auf der Parameterseite des description-Parameters.

Wichtige Punkte

Verweise auf `yesno`-Felder

Beim Verweis auf den Wert eines yesno-Felds wird zwischen Groß- und Kleinschreibung unterschieden. Verwenden Sie Yes oder No. Beispiel:

{% dynamic if value == 'Yes' %}

Logische Operatoren mit Liquid-Variablen verwenden

Sie können die logischen Operatoren and, or und not mit Flüssigkeitsvariablen verwenden. Bei logischen Operatoren in Liquid ist die Groß- und Kleinschreibung zu beachten und sie müssen in Kleinbuchstaben geschrieben werden. Beispiel:

{% dynamic if value == "Shirt" or value == "Shoes" %}
  This is a shirt or shoes.
{% dynamic endif %}

Fehler „Variable nicht gefunden“

Dieser Fehler kann beispielsweise auftreten, wenn Sie {{ }} und {% %} gleichzeitig verwenden:

{% if value > {{ search_latency_top_hr.limit_95._value }} %}

Gehen Sie stattdessen so vor:

{% dynamic if value > search_latency_top_hr.limit_95._value %}

Wenn Sie einen Vorlagenfilter verwenden, prüfen Sie, ob Sie auf einen Tabellennamen verweisen, den Sie nicht mit der abgeleiteten Tabelle verknüpft haben.

Namenskonventionen können sich auf die Abfragegruppierung auswirken

Wenn es ein Feld mit dem Namen value gibt, wird es in der GROUP BY-Klausel einer Abfrage vom Typ „Erkunden“ verwendet, wenn auf die value Flüssigkeitsvariable in einem anderen Feld innerhalb derselben Ansicht verwiesen wird.

Beispiel:

dimension: id {
  primary_key: true
  type: number
  sql: ${TABLE}.id ;;
  html:
    {% dynamic if value > 10 %}
      <font color="darkgreen">{{ rendered_value }}</font>
    {% elsif value > 11 %}
      <font color="goldenrod">{{ rendered_value }}</font>
    {% dynamic else %}
      <font color="darkred">{{ rendered_value }}</font>
    {% dynamic endif %} ;;
}

dimension: value {
  sql: ${TABLE}.status ;;
  type: string
}

Dadurch wird die folgende SQL-Datei generiert, wenn in einem Explore nur id ausgewählt ist:

SELECT
orders.id AS orders.id,
orders.status AS orders.value
FROM order_items
LEFT JOIN orders ON order_items.order_id = orders.id

GROUP BY 1,2
ORDER BY orders.id
LIMIT 500

Achten Sie darauf, dass die Variable value auf den Namen des Felds ausgerichtet ist, um explizit auf das Feld zu verweisen, um dieses Gruppierungsverhalten zu vermeiden:

dimension: id {
  primary_key: true
  type: number
  sql: ${TABLE}.id ;;
  html:
    {% dynamic if value > 10 %}
      <font color="darkgreen">{{ id._rendered_value }}</font>
    {% elsif value > 11 %}
      <font color="goldenrod">{{ id._rendered_value }}</font>
    {% dynamic else %}
      <font color="darkred">{{ id._rendered_value }}</font>
    {% dynamic endif %} ;;
}

Für die Verwendung von `_filters['view_name.field_name']` in einer abgeleiteten Tabelle ist `sql_quote` erforderlich

Wenn Sie eine SQL-basierte abgeleitete Tabelle definieren und die _filters['view_name.field_name'] Liquid-Variable verwenden, bei der der Wert in SQL gerendert wird, und der Filter einen String-Wert zurückgibt, müssen Sie einfache Anführungszeichen um die Ausgabe setzen. Füge dazu den Filter „Flüssigkeit“ sql_quote hinzu.

Beispiel für die Verwendung einer der folgenden Flüssigkeitsvariablen im Parameter sql eines derived_table-Parameters:

{{ _filters['view_name.field_name'] }}

oder

{% assign foo = _filters['view_name.field_name']  %} foo

Sie können den Liquid-Filter | sql_quote an die Deklaration der Liquid-Variable anhängen:

{{ _filters['view_name.field_name'] | sql_quote }}

und

{% assign foo = _filters['view_name.field_name'] | sql_quote %} foo

Hier ein Beispiel für eine abgeleitete Tabelle mit der Variable _filters['view_name.field_name']:

view: users_sql_based_dt {
  derived_table: {
    sql:
    SELECT
      users.id AS id,
          (DATE(users.created_at)) AS created_date,
      users.city AS city,
      COUNT(*) AS user_count
    FROM
        public.users AS users
    {% dynamic if users_sql_based_dt.city._is_filtered %}
      WHERE
        users.city = {{ _filters['users_sql_based_dt.city'] | sql_quote  }}
    {% dynamic endif %}
    GROUP BY
        1,
        2,
        3
    ORDER BY
        2 DESC
      ;;
  }

Das Feld city ist ein String, der in SQL ausgegeben wird. Der Flüssigkeitsfilter sql_quote ist also erforderlich, damit das Ausgabe-SQL in einfache Anführungszeichen gesetzt wird. Wenn ein Nutzer im Ergebnis der explorativen Datenanalyse den Namen einer Stadt als Filter angibt, schließt Looker den String des Ortsnamens in Anführungszeichen ein. Looker sendet diesen SQL an die Datenbank, wenn ein Nutzer die Abfrage „Erkunden“ nach dem Stadtwert New York filtert:

WHERE
    users.city = 'New York'

Wenn Sie die _filters['view_name.field_name']Liquid-Variable für ein Stringfeld in einer abgeleiteten Tabelle verwenden, in der der Wert in SQL gerendert wird, erhalten Sie die folgende LookML-Warnung, wenn Sie | sql_quote nicht an die Liquid-Variable anhängen:

Using "_filters[]" in Derived Table SQL without "sql_quote" is discouraged.

Sie können auch sql_quote mit dieser Syntax verwenden, um mehrere Werte in einem Array zu zitieren:

{{ _filters['view_name.field_name'] | split:"," | sql_quote | join:"," }}

Hier ein Beispiel, in dem die Flüssigkeitsausgabe als Eingabe für eine IN-Anweisung verwendet wird:

 WHERE
    users.city IN({{ _filters['users_sql_based_dt.city'] | split:"," | sql_quote | join:"," }})

Mit dieser Syntax werden in der Liquid-Ausgabe Anführungszeichen um jeden einzelnen Wert ('value1','value2','value3') und nicht in Anführungszeichen um die vollständige Liste ('value1, value2, value3') gesetzt.

Flüssigkeitsvariablen in aggregierten Messwerten wirken sich auf die Gruppierung aus

Wenn Sie die Syntax {{ view_name.field_name._value }} oder {{ field_name._value }} im Parameter link oder html einer Messung verwenden, um auf einen Wert aus einem anderen Feld zu verweisen, ruft Looker dieses Feld in die SQL-Abfrage ab, um den Feldwert zu erfassen. Liquid kann sich darauf auswirken, wie SQL-Abfragen generiert werden und wie viele Spalten die GROUP BY-Klausel verwendet. Das kann zu unerwartetem Verhalten führen, wenn Sie mit aggregierten Messwerten wie type: count arbeiten.

Angenommen, Sie haben die folgenden zwei Messwerte:

measure: count_without_liquid {
  type: count
}

measure: count_with_liquid {
  type: count
  link: {
    label: "Status Count"
    url: "https://www.google.com/search?q={{ status._value }}"
  }
}

Wenn Sie mit der Messung count_without_liquid eine Abfrage generieren, erhalten Sie die folgenden Ergebnisse:

Ergibt die Datentabelle für eine Abfrage, in der die Felder „Erstellter Monat“ und „Anzahl ohne Flüssigkeit“ ausgewählt sind.

In diesem Fall gibt die Abfrage eine einzelne Anzahl für jeden Monat zurück. Als Nächstes wird der SQL-Code angezeigt, der für die vorherigen Ergebnisse generiert wurde:

SELECT
  TO_CHAR(DATE_TRUNC('month', order_items.created_at ), 'YYYY-MM') AS "order_items.created_month",
  COUNT(*) AS "order_items.count_without_liquid"
FROM order_items AS order_items

GROUP BY DATE_TRUNC('month', order_items.created_at )
ORDER BY 1 DESC
LIMIT 500

Wenn Sie jedoch eine Abfrage mit der Messung count_with_liquid generieren, erhalten Sie folgende Ergebnisse:

Ergibt die Datentabelle für eine Abfrage, in der die Felder „Erstellter Monat“ und „Anzahl erstellen“ mit den Flüssigkeitsfeldern ausgewählt sind.

Dieses Beispiel zeigt, dass Sie nicht die Anzahl jedes Monats in der Abfrage, sondern jeden Monat und jeden Status erhalten. Das liegt daran, dass im generierten SQL-Feld das Feld status zur Abfrage hinzugefügt wurde, damit ihr Wert abgerufen werden kann. Da sie der Abfrage hinzugefügt wurden, wurde sie auch der GROUP BY-Klausel hinzugefügt:

SELECT
  TO_CHAR(DATE_TRUNC('month', order_items.created_at ), 'YYYY-MM') AS "order_items.created_month",
    order_items.status AS "order_items.status",
    COUNT(*) AS "order_items.count_without_liquid"
FROM order_items AS order_items

GROUP BY DATE_TRUNC('month', order_items.created_at ),2
ORDER BY 1 DESC
LIMIT 500

Eine Möglichkeit, dies zu verhindern, besteht darin, die Funktion row[] mit der Liquid-Variable zu verwenden, die ihren Wert aus den gerenderten Ergebnissen im Browser abruft und daher das referenzierte Feld nicht in die SQL-Abfrage einfügt:

  link: {
    label: "{% dynamic if row['view_name.field_name'] %} some_label {% dynamic endif %}"
    url: "https://www.google.com/search?q={{ row['view_name.field_name'] }}"
  }

Wenn Sie diese Syntax verwenden, funktioniert der link-Parameter nur, wenn das Feld auf andere Weise ausgewählt oder in die Abfrage aufgenommen wurde.

Die Summe der row[]-Syntax führt nicht dazu, dass das Feld der Abfrage hinzugefügt wird, wie es bei {{ field_name._value }} der Fall ist. Durch das dynamische Label erhält der Link kein Label, wenn das Feld nicht verfügbar ist. Das führt dazu, dass der Link aus dem Linkmenü verschwindet.