Riferimento per le variabili liquide

Liquid è un linguaggio di modello che puoi utilizzare in Looker per creare contenuti più dinamici. Ad esempio, potresti creare gli 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.

Gli estratti conto liquidi sono costituiti 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 i filtri e i tag, descritti in questa guida ai liquidi.

In LookML puoi utilizzare Liquid in diversi modi:

• Il parametro action
• Il parametro description di un campo (ma non di un'esplorazione)
• Il parametro html
• Etichetta i parametri 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)
• Parametro del filtro della dashboard di default_value
• Il parametro dell'elemento della dashboard filters

Utilizzo delle variabili per liquidi

L'utilizzo di base delle variabili Liquid è semplice. Una volta identificata la variabile che vuoi utilizzare (vedi il seguente elenco), è sufficiente inserirla in un parametro LookML valido. Successivamente, vengono definite le variabili Liquid specifiche che puoi utilizzare in specifici parametri LookML.

Due tipi di utilizzo di liquidi

Ci sono due modi per utilizzare una variabile Liquido:

1. Sintassi di output: questo tipo di utilizzo può inserire testo ed è probabilmente il modo più comune per utilizzare liquidi in Looker. In questo metodo, racchiudi la variabile Liquid in due parentesi graffe. Ad esempio: {{ value }}
2. Sintassi dei tag: questo tipo di utilizzo in genere non prevede l'inserimento di testo, ma viene utilizzato per confronti logici e altre operazioni su liquidi. In questo metodo, racchiudi la variabile Liquid in una parentesi graffa e un segno di percentuale singola. Ad esempio: {% dynamic if value > 10000 %}

Esempi di base

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

dimension: product_image {
  sql: ${product_id} ;;
  html: <img src="https://www.altostrat.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 che lo riguarda.

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 per controllare e reagire 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 dell'etichetta, la dimensione email cambia il proprio valore label a seconda del nome del modello LookML. In questo modo, il nome del campo nel selettore campi e nei risultati delle query che includono la dimensione email viene modificato in modo dinamico:

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.

Accedere alle variabili da altri campi

Le variabili liquide di solito si basano sul campo in cui vengono utilizzate. Tuttavia, se necessario, puoi accedere ai valori anche da 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 Liquid di Looker. Verifica che il nome della variabile sia preceduto da un trattino basso, a differenza di quanto segue:

• {{ 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 l'accesso a un URL del 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 Liquid di {{ field_name._value }}, il campo di riferimento viene aggiunto alla clausola SELECT della query SQL e viene aggiunto come colonna aggiuntiva nella clausola GROUP BY. Questa operazione è necessaria 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 liquide nelle misure aggregate in questa pagina.

Definizioni delle variabili liquide

La tabella seguente descrive le variabili Liquid che puoi utilizzare con LookML. La colonna Utilizzo indica i parametri LookML con cui è possibile utilizzare 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 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, tra cui il parametro label, il parametro view_label, il parametro group_label e il parametro group_item_label, ma non funzionano con i parametri delle etichette a livello di modello, Explore, View o Line di riferimento oppure 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 parametro secondario 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 di formattazione delle date in rendered_value, come mostrato nella pagina Facilità di formattazione delle date con le liquide Best Pratiches. 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 filtri in base a un valore stringa che include una virgola come "Altostrat, Inc", la variabile value restituisce due stringhe diverse, "Altostrat" e "Inc". La variabile filterable_value corregge questo problema inserendo caratteri di escape e restituisce una singola stringa, in questo esempio "Altostrat, Inc".	A H LI	8521935
Link
link	L'URL del link di visualizzazione 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 e il collegamento predefiniti di Looker. Le misure non hanno un collegamento predefinito, pertanto 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 il criterio 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, è necessario il filtro Liquido sql_quote.	A DE H LA LI	NOT NULL
{% date_start date_filter_name %}	La data di inizio in un filtro di data richiesta con date_filter_name. Consulta la sezione Utilizzo di date_start e date_end per ulteriori informazioni.	S	2017-01-01
{% date_end date_filter_name %}	La data di fine in un filtro di data richiesta con date_filter_name. Consulta la sezione Utilizzo di date_start e date_end per ulteriori informazioni.	S	2017-01-01
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}	Il valore del filtro che hai richiesto con filter_name, applicato a sql_or_lookml_reference come SQL. Questa variabile viene utilizzata con i filtri basati su modelli e i join condizionali.	S	Per vedere alcuni esempi, consulta la pagina della documentazione Filtri basati su modelli e la sezione Condizioni condizionali della pagina della documentazione di sql_on.
{% parameter parameter_name %}	Il valore del filtro parametro richiesto con parameter_name.	DE LA S	Per vedere alcuni esempi, consulta la pagina della documentazione relativa al parametro parameter.
parameter_name._parameter_value	Inserire il valore del filtro parametro con parameter_name in un'istruzione logica.	DE H LA LI S	Consulta la pagina della documentazione relativa al parametro parameter per dettagli ed esempi importanti.
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 gli attributi vengono utilizzati. La variabile _user_attributes['name_of_attribute'] può essere utilizzata anche nella sintassi del filtro avanzata.	A DE H LA LI S DV F	Northeast (se, ad esempio, l'attributo utente era "region") Per un ulteriore esempio, consulta la pagina Utilizzo degli attributi utente per schema dinamico e inserimento di nomi di tabella.
_localization['localization_key']	Restituisce il valore associato a una chiave di localizzazione definita nel file stringa di un modello in base alle impostazioni internazionali dell'utente.	DV F	Per un esempio, consulta la pagina della documentazione Localizzazione del modello LookML.
Oggetti LookML
_model._name	Il nome del modello per questo campo.	A DE H LA LI S	look
_view._name	Il nome della visualizzazione per questo campo.	A DE H LA LI S	ordini
_explore._name	Il nome dell'esplorazione per questo campo.	A DE H LA LI S	elementi_ordine
_explore._dashboard_url	AGGIUNTO 22.12 L'URL relativo per la dashboard corrente.	H LI S	/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 che hai richiesto con view_name.field_name è presente nella tabella dei dati della query, è incluso in un filtro per una query o è 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 che chiedi con view_name.field_name viene visualizzato nella tabella di 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 di 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 i seguenti 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 valutata fino al 1° aprile 2022; la filter_end viene valutata fino al 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 Liquid, 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 corrisponderà a NULL. Ad esempio, utilizzando l'esempio, se in Esplora un utente imposta new_filter_test prima del 07/06/2022, l'output {% date_start date_filter %} sarà NULL, poiché l'utente ha specificato un intervallo con una data di fine ma nessuna 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 uno di questi scenari 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, come IFNULL o COALESCE, a seconda del dialetto del database.

Consulta la pagina sulle best practice per l'utilizzo di date_start e date_end per una spiegazione approfondita su come utilizzare le variabili Liquid di date_start e date_end per gestire le tabelle partizionate in base alle date.

Per conoscere un esempio di utilizzo di date_start e date_end per l'analisi flessibile di periodo, consulta il post della scheda Community sull'analisi flessibile tra periodi di Analytics.

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 giusto di riferimento per la variabile Liquid.

Per determinare se qualcosa è incluso nella query e inserire un determinato testo in base a questo, devi utilizzare un pattern come il 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 "vero" o "falso", utilizza un pattern come il seguente:

{{ view_name.field_name._in_query }}

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

{{ view_name.field_name._in_query | sql_boolean }}

Gli stessi pattern si applicano alle variabili _is_selected e _is_filtered.

Utilizzo delle variabili Liquid con il parametro label

Puoi utilizzare le variabili liquide nel parametro label di un campo per modificare dinamicamente 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 funzionano 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 influenzare 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 riportata sopra, 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 modificheranno il nome del campo nel selettore campi. In questi casi, il nome del campo verrà modificato solo nella visualizzazione risultante.

Quando utilizzi la variabile Liquid 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 dinamicamente la descrizione di un campo. Questa descrizione viene visualizzata quando gli utenti passano il mouse sopra l'icona delle informazioni del campo nel selettore campi, il nome della colonna nella sezione dati dell'esplorazione o il nome della colonna del campo in un grafico a tabella. Consulta la tabella nella sezione Definizioni delle variabili liquide 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 funzioneranno con il parametro description a livello di Esplora.

Le seguenti variabili possono essere utilizzate con description per influire sul selettore campi, la sezione dati di un'esplorazione e l'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 riportata sopra, come le variabili Liquid che restituiscono un valore in base a un filtro (come _filters), o richiedono l'esecuzione di una query prima che sia possibile determinare il valore della variabile (come in_query), non cambierà la descrizione nel selettore campi o nella sezione dei dati di un'esplorazione. Queste variabili Liquid interessano solo la descrizione visualizzata quando un utente posiziona il puntatore del 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 del parametro description.

Aspetti da considerare

Riferimento ai campi yesno

Per fare riferimento al valore di un campo yesno, il valore è sensibile alle maiuscole. Utilizza il Yes o No. Ecco alcuni esempi:

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

Utilizzo di operatori logici con variabili Liquid

Puoi utilizzare gli operatori logici and, or e not con le variabili Liquid. Gli operatori logici in Liquid sono sensibili alle maiuscole e devono essere scritti interamente in minuscolo. Ecco alcuni esempi:

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

Viene visualizzato l'errore "Variabile non trovata"

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

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

Segui questi passaggi:

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

Se utilizzi un filtro basato su modelli, controlla se fai riferimento a un nome 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 campo verrà incluso nella clausola GROUP BY di una query Explore quando viene fatto riferimento alla variabile Liquid value in un altro campo all'interno della stessa vista.

Ecco alcuni esempi:

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
}

Verrà generato il seguente SQL quando in un'esplorazione è selezionato solo id:

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 esplicitamente 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

Quando definisci una tabella derivata 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 virgolette singole intorno all'output. Puoi farlo includendo 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 Liquido | sql_quote alla dichiarazione della variabile Liquido:

{{ _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 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à creata in SQL, quindi il filtro Liquid di 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 sul 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 di Liquid includerà virgolette per ogni singolo valore ('value1','value2','value3') anziché virgolette per intero ('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 estrae quel campo nella query SQL per recuperarlo. 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 comportamenti imprevisti durante l'utilizzo di misure aggregate, come quelle 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. L'SQL 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 avviene perché, nell'SQL generato, il campo status è stato aggiunto alla query in modo da poterne recuperare il valore. Inoltre, 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 ciò 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'] }}"
  }

Se 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 comporterà l'aggiunta del campo alla query, come accade in {{ field_name._value }}. Se il campo non è disponibile, l'etichetta dinamica non avrà un'etichetta e il link scomparirà dal menu dei link.