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

Diese Seite wurde von der Cloud Translation API übersetzt.

Referenz für Flüssigkeitsvariablen

Liquid ist eine Vorlagensprache, mit der Sie in Looker dynamischere Inhalte erstellen können. So können Sie beispielsweise URLs auf Grundlage der Ergebnisse einer Abfrage zu externen Tools erstellen oder ändern, welche Datenbanktabelle basierend 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. Sie können diese Werte mithilfe von Filtern und Tags weiter ändern. Weitere Informationen finden Sie in diesem Leitfaden.

Sie können Liquid an mehreren Stellen in LookML verwenden:

Parameter action
Der Parameter description eines Felds (aber nicht „Entdecken“)
Parameter html
Labelparameter auf Feldebene, einschließlich der Parameter label, view_label, group_label und group_item_label
Parameter link
Parameter, die mit sql beginnen, z. B. sql und sql_on
Dashboard-Filterparameter default_value
Dashboard-Elementparameter des filters

Liquid-Variablen verwenden

Die grundlegende Verwendung von Liquid-Variablen ist unkompliziert. Nachdem Sie die gewünschte Variable ermittelt haben (siehe folgende Liste), fügen Sie sie einfach in einen gültigen LookML-Parameter ein. Als Nächstes werden die spezifischen Liquid-Variablen definiert, die Sie in bestimmten LookML-Parametern verwenden können.

Zwei Arten von Liquid-Verwendung

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

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

Grundlegende 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.brettcase.com/product_images/{{ value }}.jpg" /> ;;
}

In diesem Beispiel der URL-Nutzung wird ein Musikername in eine URL eingefügt, um eine Google-Suche für diesen Musiker zu starten.

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 vom Nutzer ausgewählten Felder ermittelt. Die Syntax verwendet eine if-else-Struktur, die andernfalls in elsif angegeben ist, um die in der Abfrage enthaltenen Felder zu prüfen und darauf 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 in Abhängigkeit vom LookML-Modellnamen. Dadurch wird der Name des Felds in der Feldauswahl und in Abfrageergebnissen, die die Dimension email enthalten, dynamisch geändert:

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 jeweiligen LookML-Parameterseite.

Auf Variablen aus anderen Feldern zugreifen

Flüssigkeitsvariablen basieren normalerweise auf dem Feld, in dem sie verwendet werden. Bei Bedarf können Sie jedoch auch auf Werte aus 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. Achten Sie darauf, dass dem Variablennamen ein Unterstrich vorangestellt ist, falls dies nicht der Fall ist:

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

Dieses Beispiel zeigt, wie eine Website-URL über ein anderes Feld aufgerufen wird:

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

Wenn Sie auf ein anderes Feld mit der Liquid-Variablensyntax {{ 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. Dies ist erforderlich, um die Werte im referenzierten Feld ordnungsgemäß abzurufen. Sie kann jedoch zu unerwarteten Ergebnissen bei den zusammengefassten Maßnahmen führen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt zur Verwendung von Liquid-Variablen in aggregierten Messwerten.

Definitionen von Liquidvariablen

In der folgenden Tabelle werden die Liquid-Variablen beschrieben, die Sie mit LookML verwenden können. In der Spalte Nutzung sehen Sie, mit welchen LookML-Parametern die einzelnen Liquid-Variablen verwendet werden können. Außerdem gibt es folgende 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, nicht aber 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. Sie funktioniert jedoch nicht mit Labelparametern auf Ebene des Modells, der Erkundungs-, Ansichts- oder Referenzlinie 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 sich auf den Wert eines Pivot-Felds beziehen. 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 Feldes mit der Standardformatierung von Looker. Sie können in der `rendered_value` auf der Seite Einfache Formatierung von Datumsangaben mit Liquid auf die Formatierungssyntax für Datumsangaben verweisen. Neben den in der Spalte Nutzung angezeigten Parametern wird `rendered_value` auch im Unterparameter `label` der `action`- und `link`-Parameter 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 ist. Wenn Sie beispielsweise nach einem Stringwert filtern, der ein Komma wie „Periaptly, Inc“ enthält, gibt die Variable `value` zwei verschiedene Strings zurück: „Periaptly“ und „Inc“. Die Variable `filterable_value` korrigiert dies, indem Sonderzeichen maskiert und ein einzelner String zurückgegeben wird, in diesem Beispiel „Periaptly, Inc“.	A H LI	8521935
Links
`link`	Die URL zum Standard-Aufschlüsselungslink von Looker. Beachten Sie, dass einige Felder keinen Standardlink haben.	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. Für Messwerte gibt es keine Standardverknüpfung. Daher muss der Parameter `drill_fields` mit `linked_value` konfiguriert werden.	A H LI	8.521.935,00$
Filter
`_filters['view_name.field_name']`	Die Nutzerfilter, die auf das von Ihnen angeforderte Feld mit `view_name.field_name` angewendet werden. `_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 der Tabelle verwenden möchten, ist der `sql_quote`-Flüssigkeitsfilter erforderlich.	A DE H LA LI	NICHT NULL
`{% date_start date_filter_name %}`	Das Startdatum eines angefragten Datumsfilters mit `date_filter_name` 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 angeforderten Filters mit `filter_name` wird auf `sql_or_lookml_reference` als SQL angewendet. Diese Variable wird mit Vorlagenfiltern und bedingten Joins verwendet.	S	Weitere Informationen finden Sie in der Dokumentation auf der Seite Vorlagenfilter und im Abschnitt Bedingte Joins auf der `sql_on`-Dokumentationsseite.
`{% parameter parameter_name %}`	Der Wert des Parameterfilters, nach dem Sie mit `parameter_name` fragen.	DE LA S	Beispiele finden Sie in der Dokumentation zum Parameter `parameter`.
`parameter_name._parameter_value`	Fügt den Wert des angefragten Parameterfilters mit `parameter_name` in eine logische Anweisung ein.	DE H LA LI S	Wichtige Details und Beispiele finden Sie auf der Dokumentationsseite zum Parameter `parameter`.
Benutzerattribute
`_user_attributes['name_of_attribute']`	Der Wert des Nutzerattributs, für das Sie `name_of_attribute` angeben, für den jeweiligen Nutzer, 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 z. B. das Nutzerattribut „Region“ lautete) Weitere Informationen finden Sie auf der Seite Best Practices für die Verwendung des dynamischen Schemas und der Tabellennamen.
`_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 LookML-Modell lokalisieren.
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`	ADDED 22.12 Die relative URL für das aktuelle Dashboard.	H LI	/dashboards/5
`_field._name`	Der Name des Felds im Format `view_name.field_name`.	A DE H LA LI S	orders.total_order_amount
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 Sie mit `view_name.field_name` abfragen, 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, das Sie mit `view_name.field_name` anfordern, in der Abfragedatentabelle angezeigt wird.	DE LA LI S	wahr
`view_name.field_name._is_filtered`	Gibt `true` zurück, wenn das Feld, das Sie mit `view_name.field_name` anfordern, in einem Filter für die Abfrage enthalten ist.	DE LA LI S	wahr

Nutzung von `date_start` und `date_end`

Die Liquid-Variablen date_start und date_end sind sehr nützlich für Datenbankdialekte, die Daten nach Datum in mehrere Tabellen partitionieren, z. B. BigQuery. Sie müssen die Tag-Syntax {% date_start date_filter_name %} oder {% date_end date_filter_name %} verwenden. Sie können die Ausgabesyntax {{ date_start date_filter_name }} oder {{ date_end date_filter_name }} nicht verwenden, obwohl diese Syntax normalerweise zum Generieren von Text verwendet wird.

Sie können beispielsweise folgende Felder 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 den Filter „Erkunden“ für den Zeitraum vom 1. April 2022 bis zum 25. Mai 2022 filtern, wird die Dimension filter_start bis zum 1. April 2022 ausgewertet, während filter_end den 25. Mai 2022 auswertet.

Hinweise zu date_start und date_end:

Wenn der Nutzer die Abfrage nicht mit dem Filter filtert, der im date_filter-Teil der Liquid-Variablen 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 nach dem Filter filtert, der im date_filter-Teil der Liquid-Variablen angegeben ist, wird das offene Ende des Bereichs in NULL aufgelöst. Wenn beispielsweise im Beispiel ein new_filter_test im Bereich „Erkunden“ auf vor dem 07.06.2022 festgelegt wird, ist die Ausgabe von {% date_start date_filter %} NULL, da der Nutzer einen Bereich mit einem Enddatum, aber ohne Startdatum angegeben hat. Wenn ein Nutzer new_filter_test auf nach dem 07.06.2022 setzt, ist die Ausgabe von {% date_end date_filter %} NULL.

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

Auf der Seite Best Practices für date_start und date_end finden Sie eine ausführliche Erläuterung zur Verwendung der Liquid-Variablen date_start und date_end für datumspartitionierte Tabellen.

Im Communitybeitrag zum flexiblen Periodenvergleich im Analyseblock finden Sie ein Beispiel für die Verwendung von date_start und date_end für die flexible Periodenanalyse.

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

Die Variablen _in_query, _is_selected und _is_filtered geben entweder den Wert „wahr“ oder „falsch“ an, wie in diesem Beispiel gezeigt. Daher ist es wichtig, den richtigen Verweis auf Liquid-Variablen zu wählen.

Wenn Sie ermitteln möchten, ob ein Teil der Anfrage Text enthält, und diesen dann entsprechend einfügen, sollten Sie ein Muster wie das folgende 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“ verwenden 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 wahren 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 Liquid-Variablen mit dem Parameter `label`

Sie können Liquid-Variablen im Parameter label eines Felds verwenden, um die Darstellung des Felds in der Feldauswahl und in Visualisierungen dynamisch zu ändern. Im Abschnitt Tabelle auf dieser Seite sehen Sie, welche Liquid-Variablen mit dem Parameter label funktionieren.

Flüssigkeitsvariablen funktionieren mit Labelparametern auf Feldebene, einschließlich der Parameter label, view_label, group_label und group_item_label. Sie funktionieren jedoch nicht mit Labelparametern auf Modell-, Erkundungs-, Ansichts- oder Referenzpositionsebene oder mit Label als Unterparameter von link.

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

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

Die anderen Liquid-Variablen, die in der Tabelle mit LA gekennzeichnet sind, z. B. Variablen, die einen Wert basierend auf einem Filter zurückgeben (z. B. _filters) oder die eine Abfrage erfordern, bevor der Variablenwert ermittelt werden kann (z. B. in_query), ändern den Feldnamen 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 label der Wert des Unterparameters value übergeben.

Verwendung von Liquid-Variablen mit dem Parameter `description`

Sie können Liquid-Variablen mit dem Parameter description verwenden, um die Beschreibung eines Felds dynamisch zu ändern. Diese Beschreibung wird angezeigt, wenn Nutzer in der Feldauswahl den Mauszeiger auf das Informationssymbol des Felds bewegen, im Bereich „Erkunden“ im Feld „Spaltenname“ oder in einem Tabellendiagramm auf den Spaltennamen. In der Tabelle im Abschnitt Definitionen von Liquidvariablen auf dieser Seite sehen Sie, welche Liquid-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“.

Die folgenden Variablen können mit description verwendet werden, um die Feldauswahl, den Datenabschnitt eines explorativen Analysetools 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 markiert sind, z. B. Liquid-Variablen, die einen Wert basierend auf einem Filter zurückgeben (z. B. _filters) oder die eine Abfrage erfordern, bevor der Variablenwert ermittelt werden kann (z. B. in_query), ändern die Beschreibung in der Feldauswahl oder im Datenabschnitt einer Erkundung nicht. Diese Flüssigkeitsvariablen wirken sich nur auf die Beschreibung aus, die angezeigt wird, wenn ein Nutzer in einem Tabellendiagramm den Mauszeiger auf die Spaltenüberschrift des Felds bewegt.

Beispiele für die Verwendung von Liquid im Parameter description finden Sie auf der Dokumentationsseite zum Parameter description.

Wichtige Punkte

Auf `yesno` Felder verweisen

Beim Verweis auf den Wert eines yesno-Felds wird die Groß- und Kleinschreibung berücksichtigt. 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 Liquid-Variablen verwenden. Bei logischen Operatoren in Liquid wird zwischen Groß- und Kleinschreibung unterschieden. Beispiel:

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

Fehlermeldung „Variable nicht gefunden“

Dieser Fehler in Liquid kann z. B. 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 Wert gibt, wird es in der GROUP BY-Klausel einer Erkundungsabfrage eingefügt, wenn auf die Liquid-Variable value in einem anderen Feld in 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 der folgende SQL-Code generiert, wenn in einem explorativen Analysetool nur die 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 Sie die Variable value auf den Namen des Felds verweisen, 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 Liquid-Variable _filters['view_name.field_name'] verwenden, bei der der Wert in SQL gerendert wird und der Filter einen Stringwert zurückgibt, müssen Sie die Ausgabe in einfache Anführungszeichen setzen. Fügen Sie dazu den Liquid-Filter sql_quote hinzu.

Beispiel: Sie verwenden eine der folgenden Liquid-Variablen im Parameter sql des Parameters derived_table:

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

oder

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

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

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

und

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

Hier ist ein Beispiel für eine abgeleitete Tabelle, in der die Variable _filters['view_name.field_name'] verwendet wird:

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 Liquid-Filter sql_quote ist also erforderlich, um sicherzustellen, dass der Ausgabe-SQL in einfache Anführungszeichen gesetzt wird. Wenn ein Nutzer im resultierenden explorativen Analysetool einen Städtenamen als Filter angibt, schließt Looker den String für den Städtenamen in Anführungszeichen ein. Looker sendet diesen SQL an die Datenbank, wenn ein Nutzer die Abfrage „Erkunden“ nach dem Wert der Stadt New York filtert:

WHERE
    users.city = 'New York'

Wenn Sie die Liquid-Variable _filters['view_name.field_name'] 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 ist ein Beispiel, in dem die Liquid-Ausgabe 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') statt in Anführungszeichen um die vollständige Liste ('value1, value2, value3') gesetzt.

Flüssigkeitsvariablen in zusammengefassten 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 eines Messwerts verwenden, um einen Wert aus einem anderen Feld zu referenzieren, ruft Looker dieses Feld in die SQL-Abfrage ab, um den Feldwert abzurufen. Liquid kann sich daher darauf auswirken, wie SQL-Abfragen generiert werden und wie viele Spalten in der GROUP BY-Klausel verwendet werden. Das kann zu unerwartetem Verhalten führen, wenn Sie mit aggregierten Messwerten wie type: count arbeiten.

Angenommen, Sie haben die folgenden zwei Maßnahmen:

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 eine Abfrage mit dem Messwert count_without_liquid generieren, erhalten Sie folgende Ergebnisse:

Ergibt eine 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. Der SQL-Code, der für die vorherigen Ergebnisse generiert wurde, wird als Nächstes angezeigt:

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 dem Messwert count_with_liquid generieren, erhalten Sie folgende Ergebnisse:

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

Dieses Beispiel zeigt, dass Sie statt einer Zählung für jeden Monat in der Abfrage eine Zählung für jeden Monat und für jeden Status erhalten. Das liegt daran, dass das Feld status im generierten SQL-Code der Abfrage hinzugefügt wurde, sodass der entsprechende Wert abgerufen werden kann. Da sie der Abfrage hinzugefügt wurde, 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-Variablen zu verwenden, die ihren Wert aus den gerenderten Ergebnissen im Browser abruft und das referenzierte Feld daher nicht zur SQL-Abfrage hinzufü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'] }}"
  }

Beachten Sie bei Verwendung dieser Syntax, dass der Parameter link nur funktioniert, wenn das Feld auf andere Weise ausgewählt oder in der Abfrage enthalten ist.

Zusammengefasst bewirkt die Verwendung der row[]-Syntax nicht, dass das Feld der Abfrage hinzugefügt wird, wie es bei {{ field_name._value }} der Fall ist. Ist das Feld nicht verfügbar, wird für den Link das Label „Link“ ohne Label angezeigt. Das führt dazu, dass der Link aus dem Linkmenü verschwindet.