Référence de variable liquide

Liquid est un langage de création de modèles que vous pouvez utiliser dans Looker pour créer du contenu plus dynamique. Par exemple, vous pouvez créer des URL vers des outils externes en fonction des résultats d'une requête ou modifier la table de base de données interrogée en fonction de la sélection d'un utilisateur.

Les déclarations de liquide sont créées à partir de variables, de filtres et de balises. Les variables contiennent les informations que vous souhaitez utiliser et les variables fournies par Looker sont décrites sur cette page. Vous pouvez modifier ces valeurs à l'aide de filtres et de tags (voir ce guide liquide).

Vous pouvez utiliser Liquid à plusieurs endroits dans LookML:

Utiliser des variables Liquid

L'utilisation de base des variables Liquid est simple. Une fois que vous avez identifié la variable que vous souhaitez utiliser (voir la liste suivante), il vous suffit de l'insérer dans un paramètre LookML valide. Les variables Liquid que vous pouvez utiliser dans des paramètres LookML spécifiques sont définies ci-dessous.

Deux types d'utilisation de liquide

Il existe deux façons d'utiliser une variable Liquid:

  1. Syntaxe de sortie: ce type d'utilisation permet d'insérer du texte. Il s'agit probablement de la méthode la plus courante pour utiliser Liquid dans Looker. Avec cette méthode, vous placez la variable Liquid entre deux accolades. Exemple : {{ value }}
  2. Syntaxe des balises : ce type d'utilisation n'insère généralement pas de texte. Il est utilisé à la place pour des comparaisons logiques et d'autres opérations Liquid. Avec cette méthode, vous placez la variable Liquid entre une accolade et un signe de pourcentage. Exemple : {% dynamic if value > 10000 %}

Exemples de base

Dans cet exemple d'utilisation HTML, un ID produit est inséré dans un tag <img> pour générer des images de produits:

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

Dans cet exemple d'utilisation d'URL, un nom d'artiste est inséré dans une URL afin de rechercher un artiste sur Google.

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"
  }
}

Dans cet exemple d'utilisation de SQL, la table de base de données est déterminée en fonction des champs choisis par l'utilisateur. La syntaxe utilise une structure if (sinon appelée elsif), else pour vérifier les champs inclus dans la requête et y répondre.

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 %} ;;

Dans cet exemple d'utilisation de libellés, la dimension email modifie sa valeur label en fonction du nom du modèle LookML. Le nom du champ sera modifié de façon dynamique dans l'outil de sélection de champ et dans tous les résultats de requête qui incluent la dimension email:

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

Pour voir d'autres exemples d'utilisation, consultez la page individuelle des paramètres LookML qui vous intéresse.

Accéder aux variables d'autres champs

Les variables de liquide sont généralement basées sur le champ où elles sont utilisées. Toutefois, vous pouvez également accéder aux valeurs d'autres champs si nécessaire.

Utilisez le format {{ view_name.field_name._liquid-variable-name }} pour accéder à d'autres champs de la même ligne dans le résultat de la requête. Remplacez _liquid-variable-name par l'une des variables Liquid de Looker. Le nom de la variable doit être précédé d'un trait de soulignement s'il ne s'agit pas d'un comportement normal, comme suit:

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

Cet exemple montre comment utiliser ce type d'utilisation pour accéder à une URL de site Web à partir d'un autre champ:

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

Lorsque vous référencez un autre champ avec la syntaxe de variable Liquid {{ field_name._value }}, le champ référencé est ajouté à la clause SELECT de la requête SQL et ajouté à la colonne GROUP BY. Cela est nécessaire pour récupérer correctement les valeurs dans le champ référencé. Cependant, cela peut entraîner des résultats inattendus dans les mesures agrégées. Pour en savoir plus, consultez la section Utiliser des variables Liquid dans les mesures agrégées de cette page.

Définitions des variables de liquide

Le tableau suivant décrit les variables Liquid que vous pouvez utiliser avec LookML. La colonne Utilisation indique les paramètres LookML avec lesquels vous pouvez utiliser chaque variable Liquid. Elle inclut les options suivantes:

A = fonctionne avec le paramètre action

DV = fonctionne avec le paramètre default_value (pour les tableaux de bord)

DE = fonctionne avec le paramètre description au niveau du champ, mais pas avec description au niveau de l'exploration

F = fonctionne avec le paramètre filters (pour les éléments du tableau de bord)

H = fonctionne avec le paramètre html

LA : fonctionne avec les paramètres de libellé au niveau du champ, y compris les paramètres label, view_label, group_label et group_item_label, mais ne fonctionne pas avec les paramètres de libellé au niveau du modèle, de l'exploration, de l'affichage ou de la référence, ou avec label comme sous-paramètre de link

LI = fonctionne avec le paramètre link

S = fonctionne avec tous les paramètres LookML commençant par sql (ex. : sql, sql_on et sql_table_name)

Variable Définition Utilisation Exemple de résultat
Valeurs des champs
value Valeur brute du champ renvoyé par la requête de base de données. Peut faire référence à une valeur de tableau croisé dynamique.

En plus des paramètres affichés dans la colonne Utilisation, value est compatible avec le sous-paramètre label des paramètres action et link.
A H LI 8521935
rendered_value Valeur du champ avec la mise en forme par défaut de Looker.

Vous pouvez référencer la syntaxe de la mise en forme des dates dans rendered_value, comme indiqué dans l'article du centre d'aide Mise en forme facile des dates.

En plus des paramètres indiqués dans la colonne Utilisation, rendered_value est compatible avec le sous-paramètre label des paramètres action et link.
A H LI 8 521 935,00 $
filterable_value Valeur du champ mis en forme pour servir de filtre dans une URL Looker.

Par exemple, lorsque vous filtrez sur une valeur de chaîne qui inclut une virgule (par exemple "Periaptly, Inc."), la variable value renvoie deux chaînes différentes, "Periaptly" et "Inc&ct;. La variable filterable_value résout le problème en échappant les caractères spéciaux et en renvoyant une seule chaîne (par exemple, "Periaptly, Inc").
A H LI 8521935
Links
link URL du lien d'analyse par défaut de Looker. Notez que certains champs n'ont pas de lien par défaut. A H LI S /explore/thelook/orders?fields=orders.order_amount&limit=500
linked_value Valeur du champ avec la mise en forme et l'association par défaut de Looker. Étant donné que les mesures n'ont pas d'association par défaut, elles doivent être configurées par le paramètre drill_fields pour fonctionner avec linked_value. A H LI 8 521 935,00$
Filtres
_filters['view_name.field_name'] Filtres utilisateur appliqués au champ que vous demandez avec view_name.field_name.

_filters['view_name.field_name'] est également accepté dans le paramètre sql d'une table dérivée, mais pas dans les autres paramètres sql.

Pour utiliser _filters['view_name.field_name'] dans le paramètre sql d'une table dérivée, vous devez utiliser le filtre sql_quote.
A DE H LA LI Ne doit pas être vide
{% date_start date_filter_name %} Date de début d'un filtre de date que vous demandez avec date_filter_name. Pour en savoir plus, consultez la section Utilisation de date_start et date_end. S 2017-01-01
{% date_end date_filter_name %} Date de fin d'un filtre de date que vous demandez avec date_filter_name. Pour en savoir plus, consultez la section Utilisation de date_start et date_end. S 2017-01-01
{% condition filter_name %}
sql_or_lookml_reference
{% endcondition %}
Valeur du filtre que vous demandez avec filter_name appliqué à sql_or_lookml_reference en tant que SQL. Cette variable est utilisée avec des filtres modélisés et des jointures conditionnelles. S Pour obtenir des exemples, consultez la page de documentation sur les filtres basés sur un modèle et la section Jointures conditionnelles sur la page de documentation de sql_on.
{% parameter parameter_name %} Valeur du filtre de paramètre que vous demandez avec parameter_name. DE LA S Consultez des exemples dans la documentation sur les paramètres parameter.
parameter_name._parameter_value Il injecte la valeur du filtre de paramètre que vous demandez avec parameter_name dans une instruction logique. DE H LA LI S Consultez la page de documentation sur les paramètres parameter pour obtenir des détails importants et des exemples.
Attributs utilisateur
_user_attributes['name_of_attribute'] Valeur de l'attribut utilisateur que vous demandez avec name_of_attribute, pour l'utilisateur qui exécute la requête, si des attributs utilisateur sont utilisés. La variable _user_attributes['name_of_attribute'] peut également être utilisée dans la syntaxe des filtres avancés. A DE H LA LI S DV F northeast
(si, par exemple, l'attribut utilisateur était "region")

Pour en savoir plus, consultez l'article du centre d'aide Utiliser des attributs utilisateur pour l'injection de schémas dynamiques et de noms de tables.
_localization['localization_key'] Renvoie la valeur associée à une clé de localisation définie dans un fichier de chaînes de modèle, basée sur les paramètres régionaux de l'utilisateur. DV F Pour voir un exemple, consultez la page Localiser votre modèle LookML.
Objets LookML
_model._name Nom du modèle pour ce champ. A DE H LA LI S le look
_view._name Nom de la vue pour ce champ. A DE H LA LI S commandes
_explore._name Nom de l'exploration pour ce champ. A DE H LA LI S order_items [articles_de_commande]
_explore._dashboard_url ADDED 22.12 URL relative du tableau de bord actuel. H LI /dashboards/5
_field._name Nom du champ lui-même, au format view_name.field_name. A DE H LA LI S commandes.total_order_amount
Queries
_query._query_timezone Fuseau horaire dans lequel la requête a été exécutée. A DE H LA LI S America/Los_Angeles
view_name._in_query Renvoie true si l'un des champs de la vue est inclus dans la requête. DE LA LI S true
view_name.field_name._in_query Renvoie true si le champ que vous demandez avec view_name.field_name apparaît dans la table de données de la requête, s'il est inclus dans le filtre d'une requête ou s'il est inclus dans la requête via le paramètre required_fields. DE LA LI S true
view_name.field_name._is_selected Renvoie true si le champ que vous demandez avec view_name.field_name apparaît dans le tableau de données de requête. DE LA LI S true
view_name.field_name._is_filtered Renvoie true si le champ que vous demandez avec view_name.field_name est inclus dans un filtre pour la requête. DE LA LI S true

Utilisation de date_start et date_end

Les variables de liquide date_start et date_end sont très utiles pour les dialectes de base de données qui partitionnent les données en plusieurs tables par date, telles que BigQuery. Notez que vous devez utiliser la syntaxe de balise {% date_start date_filter_name %} ou {% date_end date_filter_name %}. Vous ne pouvez pas utiliser la syntaxe de sortie {{ date_start date_filter_name }} ni {{ date_end date_filter_name }}, même si elle est habituellement utilisée pour générer du texte.

Par exemple, vous pouvez créer les champs suivants dans une vue:


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 %} ;;
}

Si vous filtrez une exploration sur new_filter_test en utilisant la plage de dates du 1er avril 2022 au 25 mai 2022, la dimension filter_start correspondra au 1er avril 2022, tandis que la dimension filter_start correspondra au 25 mai 2022.

Notez les points suivants concernant date_start et date_end :

  • Si l'utilisateur ne filtre pas la requête à l'aide du filtre spécifié dans la partie date_filter de la variable Liquid, {% date_start date_filter %} et {% date_end date_filter %} sont tous deux considérés comme nuls.

  • Si l'utilisateur filtre la requête avec une plage ouverte sur le filtre spécifié dans la partie date_filter de la variable Liquid, l'extrémité ouverte de la plage renvoie la valeur NULL. Par exemple, dans l'exemple, si l'utilisateur définit new_filter_test sur avant le 07/06/2022, la sortie {% date_start date_filter %} sera NULL, car l'utilisateur a spécifié une plage avec une date de fin, mais pas de date de début. Si un utilisateur définit new_filter_test après 2022-06-07, la sortie {% date_end date_filter %} sera NULL.

Dans les deux cas où la sortie Liquid peut générer un résultat NULL, veillez à inclure une fonction SQL dans le paramètre sql pour tenir compte des valeurs NULL, telles que IFNULL ou COALESCE, en fonction du dialecte de votre base de données.

Pour obtenir des explications détaillées sur l'utilisation des variables Liquid date_start et date_end pour gérer les tables partitionnées par date, consultez la page Utiliser des dates de début et de fin.

Consultez l'article du centre d'aide sur le blocage de périodes d'analyse flexibles dans le centre d'aide pour obtenir un exemple d'utilisation de date_start et date_end pour effectuer des analyses de périodes flexibles.

Utilisation de _in_query, _is_selected et _is_filtered

Notez que les variables _in_query, _is_selected et _is_filtered fournissent une valeur vraie ou fausse, comme illustré dans cet exemple. Il est donc important de choisir le bon type de référence pour les variables Liquid.

Si vous souhaitez déterminer si un élément est inclus dans votre requête, puis insérez un texte basé sur celui-ci, vous devez utiliser le format suivant:

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

Si vous souhaitez insérer littéralement le mot "true" ou "false", utilisez un modèle comme celui-ci:

{{ view_name.field_name._in_query }}

Certains dialectes SQL ne prennent pas en charge les mots littérals "true" et "false". Dans ce cas, vous pouvez ajouter le filtre sql_boolean pour obtenir les valeurs "true" et "false" dont vous avez besoin:

{{ view_name.field_name._in_query | sql_boolean }}

Les mêmes schémas s'appliquent aux variables _is_selected et _is_filtered.

Utilisation de variables Liquid avec le paramètre label

Vous pouvez utiliser des variables Liquid dans un paramètre de champ label pour modifier de façon dynamique l'apparence du champ dans l'outil de sélection de champ et dans les visualisations. Consultez la section Tableau de cette page pour connaître les variables Liquid compatibles avec le paramètre label.

Les variables de liquide fonctionnent avec les paramètres d'étiquette au niveau du champ, y compris les paramètres label, view_label, group_label et group_item_label, mais ne fonctionnent pas avec les paramètres d'étiquette au niveau du modèle, de l'exploration, de l'affichage ou de la référence, ni avec l'étiquette comme sous-paramètre de link.

Les variables suivantes peuvent être utilisées avec label pour affecter le sélecteur de champ, les en-têtes de colonne dans la section de données d'une exploration et les visualisations:

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

Les autres variables Liquid marquées LA dans le tableau ci-dessus, telles que celles qui renvoient une valeur basée sur un filtre (comme _filters) ou qui nécessitent l'exécution d'une requête pour que la valeur de la variable puisse être déterminée (comme in_query), ne changent pas le nom du champ dans l'outil de sélection de champ. Dans ce cas, le nom du champ ne sera modifié que dans la visualisation obtenue.

Lorsque vous utilisez la variable Liquid parameter avec label, label transmet la valeur du sous-paramètre value.

Utilisation de variables Liquid avec le paramètre description

Vous pouvez utiliser des variables Liquid avec le paramètre description pour modifier de façon dynamique la description d'un champ. Cette description s'affiche lorsque les utilisateurs passent la souris sur l'icône d'informations du champ dans l'outil de sélection de champs, le nom de la colonne du champ dans la section de données de l'onglet "Explorer" ou le nom de la colonne du champ dans un graphique de table. Pour identifier les variables Liquid compatibles avec le paramètre description, reportez-vous au tableau de la section Définitions des variables liquides de cette page.

Les variables de liquide ne fonctionnent avec le paramètre description qu'au niveau du champ. Ils ne fonctionneront pas avec le paramètre description au niveau de l'exploration.

Les variables suivantes peuvent être utilisées avec description pour affecter le sélecteur de champ, la section de données d'une exploration et l'en-tête de colonne d'un graphique de table:

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

Les autres variables Liquid marquées d'un DE dans le tableau ci-dessus, telles que les variables Liquid qui renvoient une valeur basée sur un filtre (comme _filters) ou qui nécessitent qu'une requête s'exécute avant que la valeur de la variable puisse être déterminée (comme in_query) ne change pas la description dans le sélecteur de champ ni dans la section de données d'une exploration. Ces variables de liquide ne s'appliquent qu'à la description affichée lorsqu'un utilisateur pointe sur l'en-tête de colonne d'un tableau.

Pour obtenir des exemples d'utilisation de Liquid dans le paramètre description, consultez la page de documentation sur le paramètre description.

Éléments à prendre en compte

Référencer des champs yesno

Pour référencer la valeur d'un champ yesno, la valeur est sensible à la casse. Utilisez Yes ou No. Exemple :

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

Utiliser des opérateurs logiques avec des variables Liquid

Vous pouvez utiliser les opérateurs logiques and, or et not avec des variables Liquid. Dans Liquid, les opérateurs logiques sont sensibles à la casse et doivent être écrits en minuscules. Exemple :

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

Obtention de l'erreur "Variable introuvable"

Cette erreur peut se produire dans Liquid si vous utilisez {{ }} et {% %} en même temps :

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

Procédez plutôt comme suit :

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

Si vous utilisez un filtre modélisé, vérifiez si vous référencez un nom de table que vous n'avez pas joint à la table dérivée.

Les conventions d'attribution de noms peuvent avoir un impact sur le regroupement des requêtes

Si un champ porte le nom value, il est inclus dans la clause GROUP BY d'une requête d'exploration chaque fois que la variable Liquid value est référencée dans un autre champ de la même vue.

Exemple :

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
}

Le code SQL suivant est généré lorsque seul l'élément id est sélectionné dans une exploration:

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

Pour éviter ce comportement de regroupement, veillez à définir la variable value avec le nom du champ pour le référencer explicitement:

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 %} ;;
}

L'utilisation de _filters['view_name.field_name'] dans une table dérivée nécessite sql_quote

Lorsque vous définissez une table dérivée de SQL, si vous utilisez la variable Liquid _filters['view_name.field_name'] dans laquelle la valeur est affichée en SQL et que le filtre renvoie une valeur de chaîne, vous devez ajouter des guillemets simples autour de la sortie. Pour cela, vous pouvez inclure le filtre sql_quote.

Par exemple, si vous utilisez l'une de ces variables Liquid dans le paramètre sql d'un paramètre derived_table:

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

ou

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

Vous pouvez ajouter le filtre Liquid | sql_quote à la déclaration de la variable Liquid:

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

et

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

Voici un exemple de table dérivée utilisant la 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
      ;;
  }

Le champ city est une chaîne qui sera envoyée en SQL. Le filtre sql_quote doit donc être placé entre guillemets simples. Dans l'exploration résultante, lorsqu'un utilisateur spécifie le nom d'une ville en tant que filtre, Looker place la chaîne du nom de la ville entre guillemets. Looker envoie ce SQL à la base de données si un utilisateur filtre la requête Explorer sur la valeur de ville New York :

WHERE
    users.city = 'New York'

Si vous utilisez la variable _filters['view_name.field_name'] de Liquid pour un champ de chaîne d'une table dérivée dans laquelle la valeur est affichée en SQL, vous recevrez l'avertissement LookML suivant si vous n'ajoutez pas | sql_quote à la variable Liquid :

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

Vous pouvez également utiliser sql_quote avec cette syntaxe pour citer plusieurs valeurs dans un tableau:

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

Voici un exemple où la sortie Liquid est utilisée comme entrée pour une instruction IN:

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

Avec cette syntaxe, la sortie Liquid aura des guillemets autour de chaque valeur ('value1','value2','value3') au lieu de guillemets autour de la liste complète ('value1, value2, value3').

Les variables de liquide des mesures agrégées affectent le regroupement

Lorsque vous utilisez la syntaxe {{ view_name.field_name._value }} ou la syntaxe {{ field_name._value }} dans le paramètre link ou html d'une mesure pour référencer une valeur d'un autre champ, Looker extrait ce champ dans la requête SQL pour récupérer la valeur du champ. Pour cette raison, Liquid peut affecter la façon dont les requêtes SQL sont générées et le nombre de colonnes utilisé par la clause GROUP BY. Cela peut entraîner un comportement inattendu lorsque vous utilisez des mesures agrégées, telles que des mesures de type: count.

Par exemple, supposons que vous ayez deux mesures:

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 }}"
  }
}

Lorsque vous générez une requête à l'aide de la mesure count_without_liquid, vous obtenez les résultats suivants:

Résultat : un tableau de données pour une requête, avec les champs "Mois de création" et "Nombre sans liquide" sélectionnés.

Dans ce cas, la requête renvoie un nombre pour chaque mois. Le code SQL généré pour les résultats précédents est affiché ci-dessous:

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

Toutefois, lorsque vous générez une requête à l'aide de la mesure count_with_liquid, vous obtenez les résultats suivants:

Résultats dans une table de données pour une requête, avec les champs "Mois de création" et "Nombre" avec les champs "Liquide" sélectionnés.

Cet exemple montre qu'au lieu de compter chaque mois dans la requête, vous recevez un décompte pour chaque mois et chaque état. En effet, dans le langage SQL généré, le champ status a été ajouté à la requête afin que sa valeur puisse être récupérée. Étant donné qu'il a été ajouté à la requête, il l'a également été à la clause GROUP BY:

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

Pour éviter cela, utilisez la fonction row[] avec la variable Liquid, qui extrait sa valeur des résultats affichés dans le navigateur et n'ajoute donc pas le champ référencé à la requête SQL:

  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'] }}"
  }

Lorsque vous utilisez cette syntaxe, notez que le paramètre link ne fonctionne que si le champ est sélectionné ou inclus dans la requête par un autre moyen.

Pour résumer, l'utilisation de la syntaxe row[] n'entraîne pas l'ajout du champ à la requête, contrairement à la requête {{ field_name._value }}. Avec le libellé dynamique, le lien n'a plus de libellé si le champ n'est pas disponible. Il disparaît alors du menu des liens.