Sie sehen sich die Dokumentation für Looker 22.16 an. Die aktuelle Dokumentation finden Sie hier.

Verweis auf Flüssigkeitsvariablen

Liquid ist eine Vorlagensprache, mit der Sie in Looker dynamischere Inhalte erstellen können. Sie können beispielsweise URLs zu externen Tools auf der Grundlage der Ergebnisse einer Abfrage 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, die Sie in diesem Leitfaden für Flüssigkeiten lesen können.

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

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

Flüssigkeitsvariablen verwenden

Die grundlegende Verwendung von Liquid-Variablen ist unkompliziert. Nachdem Sie die Variable ermittelt haben, die Sie verwenden möchten (siehe folgende Liste), fügen Sie sie einfach in einen gültigen LookML-Parameter ein. Als Nächstes werden die spezifischen Liquidvariablen 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. Sie ist wahrscheinlich die gängigste Methode, um Liquid in Looker zu verwenden. Bei dieser Methode setzen Sie die Variable Liquid in zwei geschweifte Klammern. Beispiel:{{ value }}
Tag-Syntax: In der Regel wird kein Text eingefügt, sondern 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 Künstlername in eine URL eingefügt, um auf Google nach diesem Künstler zu suchen.

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 bestimmt. Die Syntax verwendet eine if-Konfiguration (elsif, angegeben als else), 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 Labelverwendung ändert die Dimension email den Wert label je nach Name des LookML-Modells. Dadurch wird der Name des Felds in der Feldauswahl und in allen 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 Verwendungsbeispiele finden Sie auf der jeweiligen LookML-Parameterseite.

Variablen aus anderen Feldern aufrufen

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 wird, wenn er normalerweise nicht so ist:

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

Das folgende Beispiel zeigt, wie Sie über ein anderes Feld auf eine Website-URL zugreifen können:

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üssigkeit {{ 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 aggregierten Messwerten führen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt zur Verwendung von Flüssigkeitsvariablen in zusammengefassten Messwerten.

Definitionen von Flüssigkeitsvariablen

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 sind die folgenden Optionen verfügbar:

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 des Parameters label, des view_label-Parameters, des group_label-Parameters und des group_item_label-Parameters. Er funktioniert jedoch nicht mit Labelparametern auf Modell-, Erkundungs-, Ansichts- oder Referenzlinienebene 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 einen Wert in einem Pivot-Feld verweisen. Neben den Parametern in der Spalte Nutzung wird `value` auch 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. Weitere Informationen finden Sie in der Syntax zur Datumsformatierung in `rendered_value`. Weitere Informationen finden Sie im Hilfeartikel Einfache Formatierung mit Liquid. Neben den Parametern in der Spalte Nutzung wird `rendered_value` auch 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 ist. Wenn Sie beispielsweise nach einem Stringwert filtern, der ein Komma enthält, z. B. „Periaptly, Inc&quot“, gibt die Variable `value` zwei verschiedene Strings zurück: „Periaptly"“ und „quot;Inc“. Die Variable `filterable_value` korrigiert dies durch Maskieren von Sonderzeichen und Zurückgeben eines einzelnen Strings, 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 Feldes mit der Standardformatierung und der Standardverknüpfung von Looker. Für Messwerte wird keine Standardverknüpfung verwendet. Daher muss der Parameter `drill_fields` konfiguriert werden, damit er mit `linked_value` funktioniert.	A H LI	8.521.935,00 $
Filter
`_filters['view_name.field_name']`	Die Nutzerfilter, die auf das Feld angewendet werden, nach dem Sie mit `view_name.field_name` suchen. `_filters['view_name.field_name']` wird auch im Parameter `sql` einer abgeleiteten Tabelle unterstützt, in anderen `sql`-Parametern jedoch nicht. Die Verwendung von `_filters['view_name.field_name']` in einer abgeleiteten Tabelle`sql` erfordert den`sql_quote`Flüssigkeitsfilter.	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, nach dem Sie fragen, wobei `filter_name` auf `sql_or_lookml_reference` als SQL angewendet wird. Diese Variable wird mit Vorlagenfiltern und bedingten Joins verwendet.	S	Beispiele finden Sie auf der Dokumentationsseite zu Vorlagenvorlagen 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 auf der Dokumentationsseite zum Parameter `parameter`.
`parameter_name._parameter_value`	Injiziert den Wert des angefragten Parameterfilters mit `parameter_name` in eine logische Anweisung.	DE H LA LI S	Wichtige Details und Beispiele auf der Dokumentationsseite zum Parameter `parameter`
Benutzerattribute
`_user_attributes['name_of_attribute']`	Der Wert des Nutzerattributs, den Sie mit `name_of_attribute` angeben, und zwar für den jeweiligen Nutzer, der die Abfrage ausführt, sofern diese verwendet wird. 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 beispielsweise das Nutzerattribut "region" war) Weitere Informationen hierzu finden Sie im Hilfeartikel Nutzerattribute für das dynamische Schema und Tabellennamen einfügen.
`_localization['localization_key']`	Gibt den Wert zurück, der mit einem Lokalisierungsschlüssel verknüpft ist, der in einer Strings-Datei eines Modells basierend auf einer Sprache des Nutzers definiert ist.	DV F	Ein Beispiel 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	Bestellpositionen
`_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 von Ihnen angeforderte Feld in der Tabelle mit den Abfragedaten angezeigt wird, 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 von Ihnen angeforderte Feld in `view_name.field_name` in der Tabelle mit den Abfragedaten 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. 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 die folgenden 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 für die Dimension filter_start der Wert 1. April 2022 und für filter_end der Wert 25. Mai 2022 ausgewertet.

Hinweise zu date_start und date_end:

Wenn der Nutzer die Abfrage nicht mit dem Filter filtert, der im Teil date_filter 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 für den Filter filtert, der im Abschnitt date_filter der Liquid-Variable angegeben ist, wird das offene Ende des Bereichs in NULL aufgelöst. Wenn beispielsweise im Beispiel ein Nutzer im Feld „Erkunden“ den Wert für new_filter_test vor 2022-06-07 festlegt, ist die Ausgabe {% date_start date_filter %} NULL, da der Nutzer einen Bereich angegeben hat, der ein Enddatum, aber kein Startdatum hat. Wenn ein Nutzer new_filter_test auf nach dem 07.06.2022 setzt, ist die {% date_end date_filter %}-Ausgabe NULL.

In diesen Fällen, in denen in der Liquid-Ausgabe ein NULL-Ergebnis angezeigt werden 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.

Eine ausführliche Erläuterung, wie Sie die Flüssigkeitsvariablen date_start und date_end für datumspartitionierte Tabellen verwenden können, finden Sie im Looker-Community-Thema date_start und date_end.

Im Artikel Flexible Period-Period-Analyse in der Analytics-Hilfe finden Sie ein Beispiel für die Verwendung von date_start und date_end für eine 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 Typ der Referenz für Flüssigkeiten auszuwählen.

Wenn Sie ermitteln möchten, ob ein Teil Ihrer Suchanfrage enthalten ist, und auf dieser Grundlage einen bestimmten Text einfügen, verwenden Sie ein Muster wie dieses:

{% 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 "true" oder "false" wortwörtlich einfügen möchten, verwenden Sie ein Muster wie dieses:

{{ view_name.field_name._in_query }}

Einige SQL-Dialekte unterstützen die wörtlichen Wörter "true" und "false" nicht. In diesem Fall können Sie den Filter sql_boolean hinzufügen, um die benötigten Werte (wahr und falsch) 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 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 Flüssigkeitsvariablen mit dem Parameter label funktionieren.

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

Die folgenden Variablen können mit label verwendet werden, um die Feldauswahl, 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 Flüssigkeitsvariablen, die in der Tabelle oben mit LA gekennzeichnet sind, z. B. Variablen, die einen Wert auf der Grundlage eines Filters zurückgeben (z. B. _filters) oder die eine Abfrage ausführen müssen, bevor der Variablenwert ermittelt werden kann (z. B. in_query), ändert nicht den Namen des Felds in der Feldauswahl. In diesen Fällen wird der Feldname nur in der resultierenden Visualisierung geändert.

Wenn Sie die Flüssigkeitsvariable parameter mit label verwenden, wird 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 eines Felds dynamisch zu ändern. Diese Beschreibung wird angezeigt, wenn Nutzer den Mauszeiger auf das Informationssymbol des Felds in der Feldauswahl, den Spaltennamen des Felds im Datenabschnitt von „Erkunden“ oder den Spaltennamen in einem Tabellendiagramm bewegen. In der Tabelle im Abschnitt Definitionen von Flüssigkeitsvariablen auf dieser Seite sehen Sie, welche Flüssigkeitsvariablen 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 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 Flüssigkeitsvariablen, die in der Tabelle oben mit DE markiert sind, z. B. Flüssigkeitsvariablen, die einen Wert auf der Grundlage eines Filters zurückgeben (z. B. _filters) oder die eine Abfrage erfordern, bevor der Variablenwert ermittelt werden kann (z. B. in_query), ändert nicht die Beschreibung in der Feldauswahl oder im Datenabschnitt einer explorativen Datenanalyse. Diese Flüssigkeitsvariablen wirken sich nur auf die Beschreibung aus, die angezeigt wird, wenn ein Nutzer den Mauszeiger in einem Tabellendiagramm auf die Spaltenüberschrift des Felds bewegt.

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

Wichtige Punkte

Auf `yesno` Felder verweisen

Beim Verweis auf ein yesno-Feld 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 wird zwischen Groß- und Kleinschreibung unterschieden 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“ wird abgerufen

Dieser Fehler in Liquid 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 Wert gibt, wird dieses Feld in der GROUP BY-Klausel einer Abfrage des Typs „Erkunden“ verwendet, wenn auf die value Flüssigkeitsvariable 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 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 verweist, um explizit auf das Feld zu verweisen:

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 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 um die Ausgabe einfache Anführungszeichen setzen. Dazu kannst du den Filter sql_quote Liquid verwenden.

Beispiel: Sie verwenden eine der folgenden Flüssigkeitsvariablen im Parameter sql eines 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 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 ist ein Beispiel für eine abgeleitete Tabelle, die die Variable _filters['view_name.field_name'] verwendet:

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. Daher ist der Flüssigkeitsfilter sql_quote erforderlich, um sicherzustellen, dass der Ausgabe-SQL in einfache Anführungszeichen gesetzt ist. Wenn ein Nutzer den Namen einer Stadt als Filter angibt, schließt Looker den String der Stadt in Anführungszeichen ein. Looker sendet dieses 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 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 Anführungszeichen um die vollständige Liste ('value1, value2, value3') angezeigt.

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

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

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

Das Ergebnis ist eine Datentabelle für eine Abfrage, in der die Felder „Erstellt in Monat“ und „Anzahl ohne Flüssigkeiten“ ausgewählt sind.

In diesem Fall gibt die Abfrage eine einzelne Anzahl für jeden Monat zurück. Als Nächstes wird der für die vorherigen Ergebnisse generierte SQL-Code 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:

Das Ergebnis ist eine Datentabelle für eine Abfrage, in der die Felder „Create Month“ und „Count with Liquid“ ausgewählt sind.

In diesem Beispiel wird anstelle der Anzahl für jeden Monat in der Abfrage die Anzahl für jeden Monat und jeden Status angezeigt. Das liegt daran, dass im generierten SQL-Feld das Feld status der Abfrage hinzugefügt wurde, damit der Wert abgerufen werden kann. Und weil es 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

Das lässt sich verhindern, indem Sie die Funktion row[] mit der Variable Liquid verwenden. Dadurch wird der Wert aus den gerenderten Ergebnissen im Browser abgerufen und das referenzierte Feld nicht in die SQL-Abfrage aufgenommen:

  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 Parameter link nur, wenn das Feld auf andere Weise ausgewählt oder in die Abfrage aufgenommen wurde.

Kurz gesagt bedeutet die Verwendung der row[]-Syntax nicht, dass das Feld der Abfrage wie {{ field_name._value }} hinzugefügt wird. Wenn das Feld nicht verfügbar ist, wird dem Link kein Label zugewiesen, sodass er nicht mehr im Linkmenü angezeigt wird.