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 instructions Liquid 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 balises (voir Guide Liquid).

Vous pouvez utiliser Liquid à différents endroits dans LookML:

• Paramètre action
• Paramètre description d'un champ (mais pas d'une exploration)
• Paramètre html
• Paramètres d'étiquette au niveau du champ, y compris label, view_label, group_label et group_item_label
• Paramètre link
• Paramètres commençant par sql (sql et sql_on, par exemple)
• Paramètre de filtre du tableau de bord default_value
• Paramètre d'élément du tableau de bord filters

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 des liquides

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. Dans 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 sert plutôt à effectuer des comparaisons logiques et d'autres opérations Liquid. Avec cette méthode, vous placez la variable Liquid entre une accolade et un signe pourcentage. Exemple : {% dynamic if value > 10000 %}

Exemples de base

Dans cet exemple d'utilisation au format 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 générer une recherche Google pour cet artiste.

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, dans le cas contraire (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 des étiquettes, la dimension email modifie sa valeur label en fonction du nom du modèle LookML. Le nom du champ sera modifié de manière dynamique dans le sélecteur de champs et dans tous les résultats de requête incluant 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 du paramètre LookML qui vous intéresse.

Accéder aux variables depuis 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. Si ce n'est pas le cas, le nom de la variable doit être précédé d'un trait de soulignement, comme dans l'exemple suivant:

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

Cet exemple illustre ce type d'utilisation pour accéder à l'URL d'un 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ée à une colonne supplémentaire de la clause GROUP BY. Cela est nécessaire pour récupérer correctement les valeurs du 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 des mesures agrégées sur 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 utilisés par chaque variable Liquid et 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 ne fonctionne pas avec description au niveau de l'exploration.

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

H = fonctionne avec le paramètre html.

LA = fonctionne avec les paramètres de libellé au niveau du champ, y compris 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 la fonctionnalité Explorer, de la vue 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 (par exemple, 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 à la valeur d'un champ croisé dynamique. En plus des paramètres indiqués dans la colonne Utilisation, value est accepté dans 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 mise en forme de la date dans rendered_value, comme indiqué dans la page Mise en forme facile des dates avec Liquid.	A H LI	8 521 935,00 $
filterable_value	Valeur du champ formaté pour être utilisé comme 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". La variable filterable_value corrige cela en échappant les caractères spéciaux et en renvoyant une seule chaîne (dans cet 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 avec le paramètre drill_fields pour fonctionner avec linked_value.	A H LI	8 521 935,00$
Filtres
_filters['view_name.field_name']	Les filtres utilisateur appliqués au champ demandé 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 d'autres paramètres sql. Utiliser _filters['view_name.field_name'] dans une table dérivée sql nécessite le filtre sql_quoteliquide.	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 de la page de documentation sql_on.
{% parameter parameter_name %}	Valeur du filtre de paramètre que vous demandez avec parameter_name.	DE LA S	Pour obtenir des exemples, consultez la page de 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 exécutant 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 (if, if the user attribute was "region") Pour en savoir plus, reportez-vous à la page 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 le fichier de chaînes d'un modèle en fonction des paramètres régionaux de l'utilisateur.	DV F	Consultez la page Localiser votre modèle LookML pour obtenir un exemple.
Objets LookML
_model._name	Nom du modèle pour ce champ.	A DE H LA LI S	Thelook
_view._name	Nom de la vue pour ce champ.	A DE H LA LI S	commandes
_explore._name	Nom de la zone "Explorer" pour ce champ.	A DE H LA LI S	commande_items
_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	orders.total_order_amount [montant_commande_totale]
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 le tableau de données de requête, s'il est inclus dans le filtre d'une requête ou s'il est inclus dans une 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 la table 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 de la requête.	DE LA LI S	true

Utilisation de date_start et date_end

Les variables Liquid 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, comme 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 cette syntaxe est généralement 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 le new_filter_test en utilisant la plage de dates allant du 1er avril 2022 au 25 mai 2022, la dimension filter_start correspondra au 1er avril 2022 et le filter_end au 25 mai 2022.

Notez les points suivants sur 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 %} renvoient une valeur NULL.

• 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 est définie sur NULL. Par exemple, dans Explorer, si un 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 sur after 07/06/2022, la sortie {% date_end date_filter %} sera NULL.

Dans les deux cas où la sortie Liquid peut afficher le résultat NULL, veillez à inclure une fonction SQL dans le paramètre sql afin de prendre en compte les 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 la gestion des tables partitionnées par date, consultez la page Utiliser les bonnes pratiques date_start et date_end.

Consultez le post de la communauté Bloc analytique Analyse flexible d'une période à l'autre pour découvrir un exemple d'utilisation de date_start et date_end pour une analyse flexible d'une période à l'autre.

Utilisation de _in_query, _is_selected et _is_filtered

Notez que les variables _in_query, _is_selected et _is_filtered fournissent une valeur "vrai" ou "faux", 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érer un texte en fonction de celui-ci, utilisez un modèle comme celui-ci:

{% 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 n'acceptent pas les mots littérals "true" et "false". Dans ce cas, vous pouvez ajouter le filtre sql_boolean pour obtenir les valeurs "vrai" et "faux" 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 des variables Liquid avec le paramètre label

Vous pouvez utiliser des variables Liquid dans le paramètre label d'un champ pour modifier de façon dynamique son apparence dans le sélecteur 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 liquides 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 en tant que 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 renvoyant une valeur basée sur un filtre (_filters, par exemple) ou nécessitant l'exécution d'une requête pour pouvoir déterminer la valeur de la variable (in_query, par exemple), ne modifient pas le nom du champ dans l'outil de sélection des champs. 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 reçoit la valeur du sous-paramètre value.

Utilisation des 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 apparaît lorsque les utilisateurs passent la souris sur l'icône d'informations du champ dans l'outil de sélection, le nom de la colonne du champ dans la section de données de l'outil Explorer ou le nom de la colonne du champ dans un graphique de tableau. Consultez le tableau de la section Définition des variables Liquid sur cette page pour connaître les variables Liquid compatibles avec le paramètre description.

Les variables liquides 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 tableau :

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

Les autres variables Liquid marquées DE dans le tableau ci-dessus, telles que les variables Liquid qui renvoient une valeur basée sur un filtre (par exemple, _filters) ou qui nécessitent une exécution de requête avant que la valeur de la variable puisse être déterminée (comme in_query) ne modifient pas la description dans le sélecteur de champ ni dans la section de données d'une exploration. Ces variables Liquid affectent la description affichée uniquement lorsqu'un utilisateur passe la souris sur l'en-tête de colonne d'un champ dans un graphique de 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érencement 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 %}

L'erreur "Variable introuvable" s'affiche

Vous pouvez obtenir cette erreur dans Liquid si vous utilisez {{ }} et {% %} en même temps, comme suit :

{% 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 basé sur un modèle, 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 affecter le regroupement de requêtes

Si un champ porte le nom value, il est inclus dans la clause GROUP BY d'une requête Explorer 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 sera généré lorsque seul l'attribut 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, assurez-vous de limiter 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 SQL, si vous utilisez la variable Liquid _filters['view_name.field_name'] où 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 ce faire, incluez le filtre Liquide 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 générée en SQL. Le filtre Liquid sql_quote doit donc être encadré par des guillemets simples. Dans l'exploration suivante, lorsqu'un utilisateur spécifie le nom d'une ville en tant que filtre, Looker encadre la chaîne correspondant au 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 Liquid _filters['view_name.field_name'] 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, le résultat Liquid est entouré de chaque valeur ('value1','value2','value3') au lieu de la liste complète ('value1, value2, value3').

Les variables liquides dans les 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 à partir d'un autre champ, Looker extrait ce champ dans la requête SQL pour récupérer la valeur du champ. Par conséquent, Liquid peut influer sur la façon dont les requêtes SQL sont générées et sur le nombre de colonnes utilisées 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 les deux mesures suivantes:

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:

Dans ce cas, la requête renvoie un seul nombre pour chaque mois. Le code SQL généré pour les résultats précédents est présenté 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:

Cet exemple montre qu'au lieu d'un décompte pour chaque mois de la requête, vous recevez un décompte pour chaque mois et pour 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. Comme il a été ajouté à la requête, il a également été ajouté à 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, vous pouvez utiliser 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'] }}"
  }

Si 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.

En résumé, l'utilisation de la syntaxe row[] n'entraîne pas l'ajout du champ à la requête, comme c'est le cas avec {{ field_name._value }}. Si le champ n'est pas disponible, l'étiquette dynamique n'aura aucun libellé, et le lien disparaîtra du menu des liens.