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:
- Paramètre
action
- Paramètre
description
d'un champ (mais pas d'une exploration) - Paramètre
html
- Paramètres d'étiquettes au niveau du champ, y compris les paramètres
label
,view_label
,group_label
etgroup_item_label
- Paramètre
link
- Paramètres commençant par
sql
(sql
etsql_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 de liquide
Il existe deux façons d'utiliser une variable Liquid:
- 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 }}
- 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 clauseSELECT
de 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 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 }}
{{ 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 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éfinitnew_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éfinitnew_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
etgroup_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 delink
.
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ètredescription
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:
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:
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.