Riferimento variabile Liquid

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

Le istruzioni liquide sono create 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, descritti in questa guida di Liquid.

Puoi utilizzare Liquid in diversi punti di LookML:

• Il parametro action
• Il parametro description di un campo (ma non di un elemento Explore)
• Il parametro html
• Etichettare 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 (come sql e sql_on)
• Il parametro del filtro della dashboard default_value
• Il parametro dell'elemento della dashboard filters

Utilizzo delle variabili di Liquid

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

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 in due parentesi graffe. Ad esempio: {{ value }}
2. Sintassi dei tag: questo tipo di utilizzo in genere non consente l'inserimento di testo, ma è utile per confronti logici e altre operazioni con Liquid. In questo metodo, racchiudi la variabile Liquid in una parentesi graffa e un segno della 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 del 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 produrre una ricerca Google dell'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 un elemento if, altrimenti se (indicato 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 suo valore label a seconda del nome del modello LookML. In questo modo, il nome del campo nel selettore campi e in tutti i risultati delle query che includono la dimensione email verrà 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 singolo 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 accedere anche ai valori di altri campi.

Usa 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. Assicurati che il nome della variabile sia preceduto da un trattino basso, se non è normalmente, ad esempio:

• {{ 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 {{ field_name._value }} della variabile Liquid, il campo di riferimento viene aggiunto alla clausola SELECT della query SQL e 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 Utilizzare le variabili Liquid in misure aggregate in questa pagina.

Definizioni delle variabili per liquidi

La tabella seguente descrive le variabili Liquid che puoi utilizzare con LookML. La colonna Utilizzo indica con quali parametri LookML è 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 esplorazione.

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 dell'etichetta a livello di modello, Esplora, Visualizzazione o Riga di riferimento 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 esempio 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 di formattazione della data in rendered_value, come mostrato nella pagina Facilità di formattazione delle date con Liquid Best Pratices. 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'utilizzo come filtro in un URL Looker. Ad esempio, quando applichi un filtro in base a un valore stringa che include una virgola come "Altostrat, Inc", la variabile value restituisce due stringhe diverse, "Altostrat" e "Inc". Per risolvere il problema, la variabile filterable_value esegue l'escape dei caratteri speciali e restituisce una singola stringa, in questo esempio "Altostrat, Inc.".	A H LI	8521935
Link
link	L'URL del link del trapano 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, quindi 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 è necessario il filtro Liquid sql_quote.	A DE H LA LI	NOT NULL
{% date_start date_filter_name %}	La data di inizio in un filtro data che richiedi con date_filter_name. Per scoprire di più, 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 richiedi con date_filter_name. Per scoprire di più, 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 che richiedi, con filter_name applicato a sql_or_lookml_reference come SQL. Questa variabile viene utilizzata con i filtri basati su modelli e le join condizionali.	S	Per vedere alcuni esempi, consulta la pagina della documentazione Filtri basati su modelli e la sezione Partecipazioni condizionali della pagina della documentazione di sql_on.
{% parameter parameter_name %}	Il valore del filtro dei parametri che richiedi con parameter_name.	DE LA S	Per vedere alcuni esempi, consulta la pagina della documentazione del parametro parameter.
parameter_name._parameter_value	Inserisci il valore del filtro parametri richiesto 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 che richiedi con name_of_attribute, per l'utente specifico che esegue la query, se vengono utilizzati gli attributi. La variabile _user_attributes['name_of_attribute'] può essere utilizzata anche nella sintassi del filtro avanzato.	A DE H LA LI S DV F	nordest (se, ad esempio, l'attributo utente era "regione") Per ulteriori esempi, consulta la pagina Best practice per l'utilizzo degli attributi utente per l'inserimento di nomi di tabelle e schemi dinamici.
_localization['localization_key']	Restituisce il valore associato a una chiave di localizzazione definita nel file stringhe 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	stile
_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	ordine_articoli
_explore._dashboard_url	AGGIUNTO 22.12 L'URL relativo della 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_ordine_importo
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 un campo della vista è incluso nella query.	DE LA LI S	true
view_name.field_name._in_query	Restituisce true se il campo che chiedi con view_name.field_name compare nella tabella dei dati di 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 hai chiesto con view_name.field_name viene visualizzato nella tabella dei dati di query.	DE LA LI S	true
view_name.field_name._is_filtered	Restituisce true se il campo che hai chiesto 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 condividono i dati in più tabelle in base alla data, come BigQuery. Tieni presente che devi utilizzare la sintassi dei 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 verrebbe utilizzata di solito 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 1° aprile 2022 - 25 maggio 2022, la dimensione filter_start riporterà il valore 1° aprile 2022; il valore filter_end riguarderà il 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 Liquid, l'estremità aperta dell'intervallo si risolverà in NULL. Ad esempio, tramite l'esempio, se in Esplora un utente imposta new_filter_test prima di 07/06/2022, l'output di {% 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 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, come IFNULL o COALESCE, a seconda del dialetto del database.

Consulta la pagina Best practice sull'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 il post della scheda Community relativo all'analisi flessibile su più periodi di Analytic Block per un esempio di come utilizzare date_start e date_end per un'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.

Per stabilire se una query è inclusa o meno nella query, inserisci un testo di conseguenza, utilizzando il seguente pattern:

{% 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 la parola "true" o "false", 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 necessari:

{{ 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 Liquid 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 Liquid 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 influire sul selettore campi, sulle intestazioni di colonna nella sezione Dati di un'esplorazione e sulle 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 (ad esempio _filters) o richiedono che venga eseguita 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 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 posizionano il mouse sopra l'icona delle informazioni del campo nel selettore campi, il nome della colonna nel campo Dati della sezione Esplora o il nome della colonna del campo in un grafico a tabella. Consulta la tabella nella sezione Definizioni delle variabili Liquid in questa pagina per vedere quali variabili Liquid funzionano con il parametro description.

Le variabili Liquid 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 determinare il 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, ad esempio le variabili Liquid che restituiscono un valore in base a un filtro (ad esempio _filters) o richiedono che una query eseguita prima di determinare il valore della variabile (come in_query) non modifichi la descrizione nel selettore campi o nella sezione dati di un'esplorazione. Queste variabili di tipo Liquid influiscono solo sulla descrizione visualizzata quando un utente passa il mouse sopra l'intestazione di colonna del campo in un grafico a tabella.

Per esempi su come utilizzare Liquid nel parametro description, consulta la pagina della documentazione del parametro description.

Aspetti da considerare

Riferimento a campi yesno

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

{% 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 in lettere minuscole. Ad esempio:

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

Visualizzare l'errore "Variabile non trovata"

Questo potrebbe verificarsi in Liquid se utilizzi {{ }} e {% %} contemporaneamente, in questo modo:

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

Prova a procedere nel seguente modo:

{% 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 nella tabella derivata.

Le convenzioni di denominazione possono influire sul raggruppamento di query

Se esiste un campo con il nome value, questo viene incluso nella clausola GROUP BY di una query Explore ogni volta che viene fatto riferimento alla variabile Liquid value in un altro campo 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
}

Quando verrà selezionato solo id in un'esplorazione, verrà generato il seguente SQL:

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 associare la variabile value al nome del campo che faccia 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 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 le virgolette singole 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

Ecco 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 assicurarti che l'SQL di output sia racchiuso tra virgolette singole. In Esplora, 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) 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, viene visualizzato 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 includerà virgolette per ogni singolo valore ('value1','value2','value3') anziché virgolette per l'intero elenco ('value1, value2, value3').

Le variabili di liquidi in misure aggregate influiscono sul raggruppamento

Quando utilizzi la sintassi {{ view_name.field_name._value }} o {{ field_name._value }} nel parametro link o html di una misura per fare riferimento a un valore di un altro campo, Looker estrae quest'ultimo 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, il che può causare un comportamento imprevisto quando lavori con misure aggregate, ad esempio type: count.

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

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 dopo:

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, ricevi un conteggio per ogni mese e per ogni stato. Questo perché, nell'SQL generato, il campo status è stato aggiunto alla query, in modo da poterne recuperare il valore. Poiché è stata aggiunta alla query, è stata aggiunta 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 interrompere questa situazione è utilizzare la funzione row[] con la variabile Liquid, che ne estrae il valore dai risultati visualizzati nel browser e pertanto 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 viene selezionato o incluso nella query in altri modi.

Per riassumere, l'uso della sintassi row[] non farà sì che il campo venga aggiunto alla query come fa {{ field_name._value }}. Se il campo non è disponibile, l'etichetta dinamica non avrà alcuna etichetta e il link scomparirà dal menu Link.