Liquid est un langage de création de modèles que vous pouvez utiliser dans Looker pour créer davantage de contenu dynamique. Par exemple, vous pouvez créer des URL d'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 construites à partir de variables, de filtres et de balises. Les variables contiennent les informations que vous souhaitez utiliser et détaillées sur cette page. Vous pouvez modifier ces valeurs à l'aide de filtres et de tags, que vous pouvez consulter dans ce guide Liquid.
Vous pouvez utiliser Liquid à plusieurs endroits dans LookML:
- Paramètre
action - Paramètre
descriptiond'un champ (mais pas d'une exploration) - Paramètre
html - Paramètres de libellé au niveau du champ, y compris les paramètres
label,view_label,group_labeletgroup_item_label - Paramètre
link - Paramètres commençant par
sql(par exemple,sqletsql_on) - 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 spécifiques que vous pouvez utiliser dans des paramètres LookML spécifiques sont définies ci-dessous.
Deux types d'utilisation de Liquid
Il existe deux façons d'utiliser une variable Liquid:
- Syntaxe de sortie: ce type d'utilisation peut insérer du texte. C'est probablement 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 }} - Syntaxe du tag: ce type d'utilisation n'insère généralement pas de texte. Il sert plutôt à des comparaisons logiques et à d'autres opérations Liquid. Avec cette méthode, vous placez la variable Liquid entre des accolades 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 une balise <img> pour générer des images de produits:
dimension: product_image {
sql: ${product_id} ;;
html: <img src="https://www.altostrat.com/product_images/{{ value }}.jpg" /> ;;
}
Dans cet exemple d'utilisation d'URL, un nom d'artiste est inséré dans une URL pour générer une recherche Google sur 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 la base de données est déterminée en fonction des champs choisis par l'utilisateur. La syntaxe utilise une structure if, sinon si (signalée par elsif) else est utilisée pour vérifier les champs inclus dans la requête et y réagir.
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 l'outil de sélection des 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 obtenir d'autres exemples d'utilisation, consultez la page de paramètre LookML qui vous intéresse.
Accéder aux variables à partir d'autres champs
Les variables Liquid sont généralement basées sur le champ dans lequel 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 Looker. Si ce n'est pas le cas, assurez-vous que le nom de la variable est précédé d'un trait de soulignement, par exemple:
{{ view_name.field_name._value }}{{ view_name.field_name._rendered_value }}{{ view_name.field_name._model._name }}
Cet exemple illustre ce type d'utilisation permettant d'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 Liquide
{{ field_name._value }}, celui-ci est ajouté à la clauseSELECTde la requête SQL et ajouté à la colonneGROUP 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 des mesures agrégées de cette page.
Définitions des variables Liquid
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. 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 d'étiquette 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 d'étiquette au niveau du modèle, de l'exploration, de l'affichage ou de la ligne de référence, ni 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 des dates dans rendered_value, comme indiqué dans la page Mise en forme simplifiée des dates avec Liquid.En plus des paramètres indiqués dans la colonne Utilisation, rendered_value est accepté dans le sous-paramètre label des paramètres action et link. | A H LI | 8 521 935,00 $ |
filterable_value | Valeur du champ formaté pour servir de filtre dans une URL Looker. Par exemple, lorsque vous filtrez une valeur de chaîne qui inclut une virgule comme "Altostrat, Inc", la variable value renvoie deux chaînes différentes, "Altostrat" et "Inc". La variable filterable_value corrige ce problème en échappant les caractères spéciaux et en renvoyant une seule chaîne. Dans cet exemple, il s'agit d'"Altostrat, Inc." | A H LI | 8521935 |
| Liens | |||
link | URL du lien d'analyse par défaut de Looker. Notez que certains champs ne sont associés à aucun 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 ne sont pas associées par défaut, elles doivent être configurées pour que le paramètre drill_fields fonctionne avec linked_value. | A H LI | 8 521 935,00$ |
| Filtres | |||
_filters['view_name.field_name'] | 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 les autres paramètres sql. Pour utiliser _filters['view_name.field_name'] dans un paramètre dérivé du tableau sql, vous devez utiliser le filtre Liquid 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 %} | La 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 | Consultez des exemples dans la page de filtres basés sur un modèle et dans 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 | Consultez des exemples sur la page de documentation des paramètres parameter. |
parameter_name._parameter_value | 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 des paramètres parameter pour obtenir des détails importants et des exemples. |
| Attributs utilisateur | |||
_user_attributes['name_of_attribute'] | La 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 | nord-est (si, par exemple, l'attribut utilisateur était "région") Pour en savoir plus, consultez la page Utiliser des attributs utilisateur pour injecter un schéma dynamique et des 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 l'exemple de la page Localiser votre modèle LookML. |
| 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 l'exploration pour ce champ. | A DE H LA LI S | commande_articles |
_explore._dashboard_url | ADDED 22.12 URL relative du tableau de bord actuel. | H LI S | /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 |
| Requêtes | |||
_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 requête, est inclus dans un filtre pour une requête ou 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 pour 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 }}{{ date_end date_filter_name }}
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 du 1er avril 2022 au 25 mai 2022, la dimension filter_start correspondra au 1er avril 2022. La filter_end sera quant à elle définie sur 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_filterde la variable Liquid,{% date_start date_filter %}et{% date_end date_filter %}renvoient la valeur NULL.Si l'utilisateur filtre la requête avec une plage ouverte sur le filtre spécifié dans la partie
date_filterde la variable Liquid, l'extrémité ouverte de la plage sera NULL. Par exemple, dans l'exemple , si un utilisateur définitnew_filter_testsur 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éfinitnew_filter_testsur after le 07/06/2022, 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 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 traiter les tables partitionnées par date, consultez la page Bonnes pratiques pour utiliser les propriétés date_start et date_end.
Pour découvrir un exemple d'utilisation de date_start et date_end pour l'analyse flexible entre les périodes, consultez le post destiné à la communauté concernant l'analyse flexible entre périodes.
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.
Pour déterminer si une requête doit être incluse ou non, insérez un texte basé sur celui-ci. Utilisez alors 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 sont pas compatibles avec 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 le paramètre label d'un champ pour modifier de façon dynamique son apparence dans l'outil de sélection de champ et dans les visualisations. Consultez la section Tableau de cette page pour savoir quelles variables Liquid fonctionneront avec le paramètre label.
Les variables Liquid fonctionnent avec les paramètres d'étiquette au niveau du champ, y compris
label,view_label,group_labeletgroup_item_label, mais ne fonctionnent pas avec les paramètres d'étiquette au niveau du modèle, de l'exploration, de l'affichage ou des références, ni avec le sous-paramètrelink.
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 des 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 signalées par LA dans le tableau ci-dessus, telles que celles renvoyant une valeur basée sur un filtre (comme _filters) ou nécessitant l'exécution d'une requête avant que la valeur de la variable puisse être déterminée (in_query, par exemple), ne modifient pas le nom du champ dans l'outil de sélection de champ. Dans ce cas, le nom du champ ne change 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 des données de la fonction Explorer ou le nom de la colonne du champ dans un graphique de table. Consultez le tableau de la section Définitions de variables Liquid de cette page pour savoir quelles variables Liquid fonctionnent avec le paramètre description.
Les variables Liquid ne fonctionnent avec le paramètre
descriptionqu'au niveau du champ. Ils ne fonctionneront pas avec le paramètredescriptionau 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 dans un graphique de tableau:
_model._name_view._name_explore._name_field._name_user_attributes['name_of_attribute']
Les autres variables Liquid signalées par DE dans le tableau ci-dessus, comme les variables Liquid qui renvoient une valeur en fonction d'un filtre (comme _filters), ou qui exigent qu'une requête s'exécute avant la valeur de variable (comme in_query) ne modifient pas la description dans le sélecteur de champ ou dans la section de données d'une exploration. Ces variables Liquid n'affectent la description affichée que lorsqu'un utilisateur pointe sur l'en-tête de colonne du 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érencer des champs yesno
Pour faire référence à 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 rencontrer 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 faites référence à 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 sera 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 à 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 basée sur SQL, si vous utilisez la variable Liquid _filters['view_name.field_name'] dans laquelle la valeur est affichée en SQL et si le filtre renvoie une valeur de chaîne, vous devez ajouter des guillemets simples autour de la sortie. Pour ce faire, ajoutez le filtre Liquid 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 placé entre guillemets simples. Dans l'exploration résultante, lorsqu'un utilisateur spécifie un nom de ville comme filtre, Looker encadre la chaîne de nom de 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 placer plusieurs valeurs entre guillemets 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 individuelle ('value1','value2','value3') au lieu de guillemets autour de la liste complète. 'value1, value2, value3'
Les variables liquides des mesures agrégées ont un impact sur le regroupement
Lorsque vous utilisez la syntaxe {{ view_name.field_name._value }} ou {{ 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. De ce fait, Liquid peut influer sur la façon dont les requêtes SQL sont générées et le nombre de colonnes utilisées par la clause GROUP BY, ce qui peut entraîner un comportement inattendu lorsque vous utilisez des mesures agrégées, telles que 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:
Dans ce cas, la requête renvoie un seul décompte par 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 indique qu'au lieu de 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 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, 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é dans 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 d'autres moyens.
En résumé, l'utilisation de la syntaxe row[] n'entraîne pas l'ajout du champ à la requête, contrairement à {{ field_name._value }}. Si le champ dynamique n'est pas disponible, le lien n'est associé à aucun libellé.