Riferimento alle variabili per liquidi

Liquid è un linguaggio di modello che puoi utilizzare in Looker per creare contenuti più dinamici. Ad esempio, puoi creare URL per strumenti esterni in base ai risultati di una query o modificare la tabella del database su cui viene eseguita la query in base alla selezione dell'utente.

Le istruzioni per i liquidi sono create a partire da variabili, filtri e tag. Le variabili contengono le informazioni che vuoi utilizzare e quelle fornite da Looker sono descritte in questa pagina. Puoi modificare ulteriormente questi valori utilizzando filtri e tag, che puoi leggere in questa guida ai liquidi.

Puoi utilizzare Liquid in diversi modi in Liquid:

• Il parametro action
• Il parametro description di un campo (ma non di un'esplorazione).
• Il parametro html
• Parametri di etichetta a livello di campo, inclusi i parametri label, view_label, group_label e group_item_label
• Il parametro link
• Parametri che iniziano con sql (ad es. sql e sql_on)
• Il parametro del filtro della dashboard default_value
• Il parametro dell'elemento della dashboard filters

Utilizzo delle variabili Liquid

L'utilizzo di base delle variabili Liquid è semplice. Dopo aver identificato la variabile che vorresti utilizzare (vedi il seguente elenco), inseriscila in un parametro LookML valido. Le variabili Liquid specifiche che puoi utilizzare in specifici parametri LookML vengono definite di seguito.

Due tipi di utilizzo di liquidi

Esistono due modi per utilizzare una variabile Liquid:

1. Sintassi dell'output: questo tipo di utilizzo può inserire testo ed è probabilmente il modo più comune per utilizzare Liquid in Looker. In questo metodo, racchiudi la variabile Liquid tra due parentesi graffe. Ad esempio: {{ value }}
2. Sintassi del tag: questo tipo di utilizzo di solito non consente di inserire testo, bensì viene utilizzato per confronti logici e altre operazioni Liquid. In questo metodo, racchiudi la variabile Liquid in una parentesi graffa e un segno percentuale. Ad esempio: {% dynamic if value > 10000 %}

Esempi di base

In questo esempio di utilizzo dell'HTML, un ID prodotto viene inserito in un tag <img> per generare le immagini prodotto:

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

In questo esempio di utilizzo dell'URL, il nome di un artista viene inserito in un URL per generare una ricerca Google relativa all'artista in questione.

dimension: artist_name {
  sql: ${TABLE}.artist_name ;;
  link: {
    label: "Google"
    url: "https://www.google.com/search?q={{ value }}"
    icon_url: "https://google.com/favicon.ico"
  }
}

In questo esempio di utilizzo di SQL, la tabella del database viene determinata in base ai campi scelti dall'utente. La sintassi utilizza una struttura if, altrimenti se (nota come elsif) else, controlla e reagisce ai campi inclusi nella query.

sql_table_name:
  {% dynamic if event.created_date._in_query %}
    event_by_day
  {% elsif event.created_week._in_query %}
    event_by_week
  {% dynamic else %}
    event
  {% dynamic endif %} ;;

In questo esempio di utilizzo delle etichette, la dimensione email cambia il suo valore label a seconda del nome del modello LookML. Questo modificherà in modo dinamico il nome del campo nel selettore di campi e in qualsiasi risultato di query che includa la dimensione 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 ;;
}

Per ulteriori esempi di utilizzo, consulta la pagina del parametro LookML che ti interessa.

Accesso alle variabili da altri campi

Le variabili di liquidi sono in genere basate sul campo in cui vengono utilizzate. Tuttavia, se necessario, puoi anche accedere ai valori di altri campi.

Utilizza il formato {{ view_name.field_name._liquid-variable-name }} per accedere ad altri campi della stessa riga nel risultato della query. Sostituisci _liquid-variable-name con una qualsiasi delle variabili di Liquid di Looker. Assicurati che il nome della variabile sia preceduto da un trattino basso se non è normale, come nell'esempio seguente:

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

Questo esempio mostra questo tipo di utilizzo per accedere all'URL di un sito web da un campo diverso:

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

Quando fai riferimento a un altro campo con la sintassi delle variabili {{ field_name._value }}, il campo a cui viene fatto riferimento viene aggiunto alla clausola SELECT della query SQL e aggiunto come colonna aggiuntiva nella clausola GROUP BY. Questo è necessario per recuperare correttamente i valori nel campo di riferimento. Tuttavia, può causare risultati imprevisti nelle misure aggregate. Per ulteriori informazioni, consulta la sezione sull'utilizzo delle variabili Liquid in misure aggregate in questa pagina.

Definizioni delle variabili in liquidi

La seguente tabella descrive le variabili Liquid che puoi utilizzare con LookML. La colonna Utilizzo indica con quali parametri LookML può essere utilizzata ogni variabile Liquid e include le seguenti opzioni:

A = funziona con il parametro action

DV = Funziona con il parametro default_value (per le dashboard)

DE = funziona con il parametro description a livello di campo, ma non funziona con description a livello di esplora

F = Funziona con il parametro filters (per gli elementi della dashboard)

H = funziona con il parametro html

LA = Funziona con i parametri dell'etichetta a livello di campo, inclusi i parametri label e view_label, group_label e group_item_label, ma non funzionano con i parametri delle etichette a livello di modello, Esplora, visualizza o fai riferimento a una riga o con label come parametro secondario di link

LI = funziona con il parametro link

S = Funziona con tutti i parametri LookML che iniziano con sql (ad es. sql, sql_on e sql_table_name)

Variabile	Definizione	Utilizzo	Output di esempio
Valori dei campi
value	Il valore non elaborato del campo restituito dalla query del database. Può fare riferimento al valore di un campo pivot. Oltre ai parametri mostrati nella colonna Utilizzo, value è supportato nel sottoparametro label dei parametri action e link.	A H LI	8521935
rendered_value	Il valore del campo con la formattazione predefinita di Looker. Puoi fare riferimento alla sintassi della formattazione della data in rendered_value, come mostrato nell'articolo del Centro assistenza Facilità di formattazione delle date con Liquid. Oltre ai parametri mostrati nella colonna Utilizzo, rendered_value è supportato nel sottoparametro label dei parametri action e link.	A H LI	8.521.935,00 $
filterable_value	Il valore del campo formattato per l'uso come filtro in un URL di Looker. Ad esempio, quando si filtra un valore di stringa che include una virgola come"Periaptly, Inc", la variabile value restituisce due diverse stringhe, "Periaptly", e"Inc". La variabile filterable_value corregge questo mediante l'escape di caratteri speciali e la restituzione di una singola stringa, in questo esempio, "Periaptly, Inc".	A H LI	8521935
Link
link	L'URL del link al drill predefinito di Looker. Tieni presente che alcuni campi non avranno un link predefinito.	A H LI S	/explore/thelook/orders?fields=orders.order_amount&limit=500
linked_value	Il valore del campo con la formattazione predefinita e il collegamento predefinito di Looker. Le misure non hanno collegamenti predefiniti, quindi le misure richiedono la configurazione del parametro drill_fields per funzionare con linked_value.	A H LI	8.521.935,00 $
Filtri
_filters['view_name.field_name']	I filtri utente applicati al campo richiesto con view_name.field_name. _filters['view_name.field_name'] è supportato anche nel parametro sql di una tabella derivata, ma non è supportato in altri parametri sql. Per utilizzare _filters['view_name.field_name'] in un parametro sql della tabella derivata è richiesto il filtro sql_quote Liquid.	A DE H LA LI	NOT NULL
{% date_start date_filter_name %}	La data di inizio in un filtro di data che chiedi con date_filter_name. Per ulteriori informazioni, consulta la sezione Utilizzo di date_start e date_end.	S	2017-01-01
{% date_end date_filter_name %}	La data finale in un filtro data che chiedi con date_filter_name. Per ulteriori informazioni, consulta la sezione Utilizzo di date_start e date_end.	S	2017-01-01
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}	Il valore del filtro richiesto con filter_name applicato a sql_or_lookml_reference come SQL. Questa variabile viene utilizzata con i filtri basati sui modelli e le unione condizionali.	S	Per vedere alcuni esempi, consulta la pagina della documentazione relativa ai filtri basati su modelli e la sezione Partecipazione condizionale della pagina della documentazione di sql_on.
{% parameter parameter_name %}	Il valore del filtro dei parametri che hai chiesto con parameter_name.	DE LA S	Per vedere alcuni esempi, consulta la pagina della documentazione relativa al parametro parameter.
parameter_name._parameter_value	Inserisci il valore del filtro parametro richiesto con parameter_name in un'istruzione logica.	DE H LA LI S	Per informazioni importanti ed esempi, consulta la pagina della documentazione relativa al parametro parameter.
Attributi dell'utente
_user_attributes['name_of_attribute']	Il valore dell'attributo utente richiesto con name_of_attribute, per l'utente specifico che esegue la query, se vengono utilizzati gli attributi utente. La variabile _user_attributes['name_of_attribute'] può essere utilizzata anche nella sintassi del filtro avanzato.	A DE H LA LI S DV F	nord-est (se, ad esempio, l'attributo utente era "region") Per un ulteriore esempio, consulta l'articolo del Centro assistenza Utilizzo degli attributi utente per schema dinamico e iniezione di nome tabella.
_localization['localization_key']	Restituisce il valore associato a una chiave di localizzazione definita nel file di stringa di un modello in base alle impostazioni internazionali di un utente.	DV F	Per un esempio, consulta la pagina della documentazione relativa alla localizzazione del modello LookML.
Oggetti LookML
_model._name	Il nome del modello per questo campo.	A DE H LA LI S	Logo Look
_view._name	Il nome della vista per questo campo.	A DE H LA LI S	ordini
_explore._name	Il nome dell'esplorazione di questo campo.	A DE H LA LI S	order_items
_explore._dashboard_url	AGGIUNTO 22.12 L'URL relativo per la dashboard corrente.	H LI	/dashboards/5
_field._name	Il nome del campo stesso, in formato view_name.field_name.	A DE H LA LI S	ordini.total_order_amount
Query
_query._query_timezone	Il fuso orario in cui è stata eseguita la query.	A DE H LA LI S	America/Los_Angeles
view_name._in_query	Restituisce true se nella query è incluso un campo della vista.	DE LA LI S	true
view_name.field_name._in_query	Restituisce true se il campo richiesto con view_name.field_name compare nella tabella di dati della query oppure se è incluso in un filtro per una query o se è incluso in una query tramite il parametro required_fields.	DE LA LI S	true
view_name.field_name._is_selected	Restituisce true se il campo richiesto con view_name.field_name viene visualizzato nella tabella dei dati della query.	DE LA LI S	true
view_name.field_name._is_filtered	Restituisce true se il campo richiesto con view_name.field_name è incluso in un filtro per la query.	DE LA LI S	true

Utilizzo di date_start e date_end

Le variabili Liquid date_start e date_end sono molto utili per i dialetti del database che suddividono i dati in più tabelle in base alla data, come BigQuery. Tieni presente che devi utilizzare la sintassi del tag {% date_start date_filter_name %} o {% date_end date_filter_name %}. Non puoi utilizzare la sintassi di output {{ date_start date_filter_name }} o {{ date_end date_filter_name }}, anche se questa sintassi viene in genere utilizzata per generare testo.

Ad esempio, puoi creare questi campi in una vista:

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

Se filtri un'esplorazione su new_filter_test utilizzando l'intervallo di date dal 1° aprile 2022 al 25 maggio 2022, la dimensione filter_start viene considerata come 1° aprile 2022, mentre filter_end viene considerata come 25 maggio 2022.

Tieni presente quanto segue su date_start e date_end:

• Se l'utente non filtra la query utilizzando il filtro specificato nella parte date_filter della variabile Liquido, sia {% date_start date_filter %} che {% date_end date_filter %} restituiscono NULL.

• Se l'utente filtra la query con un intervallo aperto sul filtro specificato nella parte date_filter della variabile Liquido, l'estremità aperta dell'intervallo si risolverà in NULL. Ad esempio, utilizzando l'esempio, se in Esplora un utente imposta new_filter_test su prima del 07-06-2022, l'output {% date_start date_filter %} sarà NULL, dato che l'utente ha specificato un intervallo che ha una data di fine ma non una data di inizio. Se un utente imposta new_filter_test su dopo il 07/06/2022, l'output di {% date_end date_filter %} sarà NULL.

In entrambi i casi in cui l'output Liquid potrebbe mostrare un risultato di NULL, assicurati di includere una funzione SQL nel parametro sql per tenere conto dei valori NULL, ad esempio IFNULL o COALESCE, a seconda del dialetto del database.

Consulta l'argomento della community di Looker Utilizzo di date_start e date_end per una spiegazione approfondita su come utilizzare le variabili Liquid date_start e date_end per gestire le tabelle partizionate in base alle date.

Consulta l'articolo del Centro assistenza Analisi flessibile su più periodi con il blocco di Analytics per un esempio di utilizzo di date_start e date_end per l'analisi flessibile tra periodi.

Utilizzo di _in_query, _is_selected e _is_filtered

Tieni presente che le variabili _in_query, _is_selected e _is_filtered forniscono un valore vero o falso, come mostrato in questo esempio. Di conseguenza, è importante scegliere il tipo di riferimento di una variabile Liquid corretto.

Per determinare se un elemento è incluso o meno nella query, quindi inserisci un determinato testo in base a questo aspetto, devi utilizzare uno schema simile al seguente:

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

Se vuoi inserire letteralmente la parola "true" o "false", utilizza un pattern come questo:

{{ view_name.field_name._in_query }}

Alcuni dialetti SQL non supportano le parole letterali "true" e "false". In tal caso, puoi aggiungere il filtro sql_boolean per ottenere i valori veri e falsi:

{{ view_name.field_name._in_query | sql_boolean }}

Gli stessi pattern vengono applicati alle variabili _is_selected e _is_filtered.

Utilizzo delle variabili Liquid con il parametro label

Puoi utilizzare le variabili Liquid nel parametro label di un campo per modificare in modo dinamico l'aspetto del campo nel selettore campi e nelle visualizzazioni. Consulta la sezione Tabella in questa pagina per vedere quali variabili Liquid funzioneranno con il parametro label.

Le variabili liquide funzionano con i parametri delle etichette a livello di campo, inclusi i parametri label, view_label, group_label e group_item_label, ma non con i parametri delle etichette a livello di modello, Esplora, Visualizza o Riga di riferimento o con etichetta come parametro secondario di link.

Le seguenti variabili possono essere utilizzate con label per determinare il selettore campi, le intestazioni di colonna nella sezione dati di un'esplorazione e le visualizzazioni:

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

Le altre variabili Liquid contrassegnate con LA nella tabella in alto, ad esempio quelle che restituiscono un valore in base a un filtro (come _filters) o che richiedono l'esecuzione di una query prima di poter determinare il valore della variabile (come in_query), non modificherà il nome del campo nel selettore di campi. In questi casi, il nome del campo viene modificato solo nella visualizzazione risultante.

Quando utilizzi la variabile Liquid di parameter con label, label viene trasmesso il valore del sottoparametro value.

Utilizzo delle variabili Liquid con il parametro description

Puoi utilizzare le variabili Liquid con il parametro description per modificare in modo dinamico la descrizione di un campo. Questa descrizione viene visualizzata quando gli utenti passano il mouse sopra l'icona delle informazioni del campo nel selettore dei campi, il nome della colonna del campo nella sezione dei dati di Esplora o il nome della colonna del campo in un grafico a tabella. Consulta la tabella nella sezione Definizioni delle variabili liquidi in questa pagina per vedere quali variabili Liquid funzionano con il parametro description.

Le variabili liquide funzionano con il parametro description solo a livello di campo. Non funzionano con il parametro description a livello di esplora.

Le seguenti variabili possono essere utilizzate con description per influire sul selettore campi, nella sezione dati di un'esplorazione e nell'intestazione della colonna in un grafico a tabella:

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

Le altre variabili Liquid contrassegnate con DE nella tabella in alto, ad esempio le variabili Liquid che restituiscono un valore in base a un filtro (come _filters) o richiedono che una query venga eseguita prima di poter determinare il valore della variabile (come in_query), non modificherà la descrizione nel selettore campi o nella sezione dati di un'esplorazione. Queste variabili Liquid interessano solo la descrizione mostrata quando un utente passa il mouse sopra l'intestazione di colonna del campo in un grafico a tabella.

Per esempi di come utilizzare Liquid nel parametro description, consulta la pagina della documentazione relativa al parametro description.

Aspetti da considerare

Fare riferimento a yesno campi

Per fare riferimento al valore di un campo yesno, il valore fa distinzione tra maiuscole e minuscole. Utilizza il Yes o No. Ad esempio:

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

Utilizzare gli operatori logici con le variabili Liquid

Con le variabili Liquid puoi utilizzare gli operatori logici and, or e not. Gli operatori logici in Liquid sono sensibili alle maiuscole e devono essere scritti in lettere minuscole. Ad esempio:

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

Recupero dell'errore "Variabile non trovata"

Un motivo per cui potresti visualizzare questo errore in Liquid è utilizzare {{ }} e {% %} contemporaneamente, in questo modo:

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

Prova a:

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

Se utilizzi un filtro basato su modelli, verifica se fai riferimento a un nome di tabella che non hai unito alla tabella derivata.

Le convenzioni di denominazione possono influire sul raggruppamento delle query

Se esiste un campo con il nome value, questo sarà incluso nella clausola GROUP BY di una query di Explore quando viene fatto riferimento alla variabile Liquid value in un altro campo all'interno della stessa vista.

Ad esempio:

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
}

Questo genererà il seguente SQL quando è selezionato solo id in un'esplorazione:

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

Per evitare questo comportamento di raggruppamento, assicurati di definire l'ambito della variabile value con il nome del campo per fare riferimento in modo esplicito al campo:

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'utilizzo di _filters['view_name.field_name'] in una tabella derivata richiede sql_quote

Durante la definizione di una tabella derivata basata su SQL, se utilizzi la variabile Liquid _filters['view_name.field_name'] in cui il valore viene visualizzato in SQL e il filtro restituisce un valore stringa, devi aggiungere singole virgolette attorno all'output. Per farlo, includi il filtro Liquido sql_quote.

Ad esempio, se utilizzi una di queste variabili Liquid nel parametro sql di un parametro derived_table:

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

o

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

Puoi aggiungere il filtro Liquid | sql_quote alla Dichiarazione della variabile Liquid:

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

e

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

Di seguito è riportato un esempio di tabella derivata che utilizza la variabile _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
      ;;
  }

Il campo city è una stringa che verrà inviata a SQL, quindi il filtro Liquid sql_quote è necessario per assicurarsi che l'SQL di output sia racchiuso tra virgolette singole. Nell'esplorazione risultante, quando un utente specifica il nome di una città come filtro, Looker racchiude la stringa del nome della città tra virgolette. Looker invia questo codice SQL al database se un utente filtra la query Explore (Esplora) nel valore della città New York:

WHERE
    users.city = 'New York'

Se utilizzi la variabile Liquid _filters['view_name.field_name'] per un campo stringa in una tabella derivata in cui il valore viene visualizzato in SQL, ricevi il seguente avviso LookML se non aggiungi | sql_quote alla variabile Liquid:

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

Puoi anche utilizzare sql_quote con questa sintassi per citare più valori in un array:

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

Ecco un esempio in cui l'output Liquid viene utilizzato come input per un'istruzione IN:

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

Con questa sintassi, l'output Liquid avrà virgolette attorno a ogni singolo valore ('value1','value2','value3') anziché contenere virgolette relative all'elenco completo ('value1, value2, value3').

Le variabili liquide nelle misure aggregate influiscono sul raggruppamento

Quando utilizzi la sintassi {{ view_name.field_name._value }} o la sintassi {{ field_name._value }} nel parametro link o html di una misura per fare riferimento a un valore di un altro campo, Looker lo include nella query SQL per recuperare il valore del campo. Per questo motivo, Liquid può influire sul modo in cui vengono generate le query SQL e sul numero di colonne utilizzate dalla clausola GROUP BY, che può causare un comportamento imprevisto quando si lavora con misure aggregate, ad esempio misure di type: count.

Ad esempio, supponiamo che tu abbia le seguenti due misure:

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

Quando generi una query utilizzando la misura count_without_liquid, ottieni i seguenti risultati:

In questo caso, la query restituisce un singolo conteggio per ogni mese. Il codice SQL che viene generato per i risultati precedenti viene mostrato di seguito:

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

Tuttavia, quando generi una query utilizzando la misura count_with_liquid, ottieni i seguenti risultati:

Questo esempio mostra che, invece di un conteggio per ogni mese nella query, si riceve un conteggio per ogni mese e per ogni stato. Questo perché, nell'SQL generato, il campo status è stato aggiunto alla query in modo che il relativo valore potesse essere recuperato. Poiché è stato aggiunto alla query, è stato aggiunto anche alla clausola 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

Un'opzione per evitare che questo accada è utilizzare la funzione row[] con la variabile Liquid, che estrae il suo valore dai risultati visualizzati nel browser e quindi non aggiunge il campo di riferimento nella query 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'] }}"
  }

Quando utilizzi questa sintassi, tieni presente che il parametro link funziona solo se il campo è selezionato o incluso nella query in altri modi.

Per riassumere, l'uso della sintassi row[] non comporta l'aggiunta del campo alla query, come invece fa {{ field_name._value }}. L'etichetta dinamica farà sì che il link non abbia etichetta se il campo non è disponibile, causando la scomparsa del link dal menu dei link.