Referencia de variable líquida

Liquid es un lenguaje de plantillas que puedes usar en Looker para crear contenido más dinámico. Por ejemplo, puedes compilar URL para herramientas externas basadas en los resultados de una consulta o cambiar la tabla de la base de datos que se consulta en función de la selección del usuario.

Las instrucciones líquidas se crean a partir de variables, filtros y etiquetas. Las variables contienen información que desea usar, y las variables que proporciona Looker se describen en esta página. Puedes modificar aún más esos valores con filtros y etiquetas, que puedes leer en esta guía sobre líquidos.

En LookML, hay varios lugares en los que puedes usar Liquid:

• El parámetro action
• El parámetro description de un campo (pero no de Explorar)
• El parámetro html
• Parámetros de etiqueta a nivel de campo, incluidos los parámetros label, view_label, group_label y group_item_label
• El parámetro link
• Parámetros que comienzan con sql (como sql y sql_on)
• El parámetro de filtro del panel default_value
• El parámetro filters del elemento del panel

Usa variables líquidas

El uso básico de las variables líquidas es sencillo. Una vez que haya identificado la variable que desea utilizar (consulte la siguiente lista), simplemente insértela en un parámetro de LookML válido. A continuación, se definen las variables líquidas específicas que puede usar en parámetros específicos de LookML.

Dos tipos de uso de líquidos

Existen dos maneras de usar una variable líquida:

1. Sintaxis de salida: Este tipo de uso puede insertar texto y es, probablemente, la manera más común de usar Liquid en Looker. En este método, encierra la variable Liquid entre dos llaves. Por ejemplo: {{ value }}
2. Sintaxis de etiquetas: Este tipo de uso no suele insertar texto; en cambio, es para comparaciones lógicas y otras operaciones de Liquid. En este método, encierra la variable líquida entre llaves y un signo de porcentaje único. Por ejemplo: {% dynamic if value > 10000 %}

Ejemplos básicos

En este ejemplo de uso de HTML, se está insertando un ID de producto en una etiqueta <img> para generar imágenes de productos:

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

En este ejemplo de uso de una URL, se inserta un nombre de artista en una URL para generar una búsqueda en Google de ese artista.

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

En este ejemplo de uso de SQL, la tabla de la base de datos se determina de acuerdo con los campos que el usuario elige. La sintaxis usa una estructura if, de lo contrario, (denotada como elsif), else, para verificar los campos incluidos en la consulta y reaccionar ante ellos.

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

En este ejemplo de uso de la etiqueta, la dimensión email cambia su valor label según el nombre del modelo LookML. Esto cambiará de forma dinámica el nombre del campo en el selector de campo y en cualquier resultado de consulta que incluya la dimensión 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 ;;
}

Para ver ejemplos de uso adicionales, consulta la página de parámetros individuales de LookML que te interese.

Cómo acceder a variables desde otros campos

Por lo general, las variables líquidas se basan en el campo en el que se usan. Sin embargo, también puedes acceder a valores de otros campos si es necesario.

Usa el formato {{ view_name.field_name._liquid-variable-name }} para acceder a otros campos desde la misma fila en el resultado de la consulta. Reemplaza _liquid-variable-name por cualquiera de las variables líquidas de Looker. Asegúrate de que el nombre de la variable esté precedido por un guion bajo si no es normalmente, como se muestra a continuación:

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

En este ejemplo, se muestra este tipo de uso para acceder a la URL de un sitio web desde un campo diferente:

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

Cuando haces referencia a otro campo con la sintaxis de la variable líquida {{ field_name._value }}, el campo al que se hace referencia se agrega a la cláusula SELECT de la consulta de SQL y a una columna adicional en la cláusula GROUP BY. Esto es necesario para recuperar correctamente los valores en el campo de referencia. Sin embargo, puede causar resultados inesperados en las medidas agregadas. Para obtener más información, consulta la sección sobre el uso de variables líquidas en medidas agregadas en esta página.

Definiciones de las variables líquidas

En la siguiente tabla, se describen las variables líquidas que puedes usar con LookML. La columna Uso indica con qué parámetros de LookML se puede usar cada variable líquida y, además, incluye las siguientes opciones:

A = Funciona con el parámetro action.

DV = Funciona con el parámetro default_value (para paneles).

DE = Funciona con el parámetro description a nivel de campo, pero no funcionará con description a nivel de Explorar.

F = Funciona con el parámetro filters (para elementos del panel).

H = Funciona con el parámetro html.

LA = Funciona con los parámetros de etiqueta a nivel de campo, incluido el parámetro label, el parámetro view_label, el parámetro group_label y el parámetro group_item_label, pero no funcionará con parámetros de etiqueta a nivel del modelo, Explorar, ver o referencia, o con label como subparámetro de link.

LI = Funciona con el parámetro link.

S = Funciona con todos los parámetros de LookML que comienzan con sql (p.ej., sql, sql_on y sql_table_name).

Variable	Definición	Uso	Resultado de ejemplo
Valores de campo
value	El valor sin procesar del campo que muestra la consulta de la base de datos. Puede hacer referencia al valor de un campo dinámico. Además de los parámetros que se muestran en la columna Uso, value se admite en el subparámetro label de los parámetros action y link.	A H LI	8521935
rendered_value	El valor del campo con el formato predeterminado de Looker. Puedes hacer referencia a la sintaxis de formato de fecha en rendered_value, como se muestra en la página Formato de fecha sencillo con las prácticas recomendadas en líquidos. Además de los parámetros que se muestran en la columna Uso, rendered_value es compatible con el subparámetro label de los parámetros action y link.	A H LI	USD 8,521,935.00
filterable_value	El valor del campo con formato para usar como filtro en una URL de Looker. Por ejemplo, cuando filtras por un valor de string que incluye una coma como “Altostrat, Inc”, la variable value muestra dos strings diferentes, “Inc.”. La variable filterable_value corrige esto al escapar caracteres especiales y mostrar una sola string, en este ejemplo, "Altostrat, Inc".	A H LI	8521935
Vínculos
link	La URL al vínculo de simulacro predeterminado de Looker. Ten en cuenta que algunos campos no tendrán vínculos predeterminados.	A H LI S	/explore/thelook/orders?fields=orders.order_amount&limit=500
linked_value	El valor del campo con el formato y la vinculación predeterminados de Looker. Las medidas no tienen un vínculo predeterminado, por lo que se debe configurar el parámetro drill_fields para que funcione con linked_value.	A H LI	USD 8,521,935.00
Filtros
_filters['view_name.field_name']	Los filtros de usuario que se aplican al campo que solicitas con view_name.field_name _filters['view_name.field_name'] también es compatible con el parámetro sql de una tabla derivada, pero no con otros parámetros sql. El uso de _filters['view_name.field_name'] en un parámetro sql de la tabla derivada requiere el filtro líquido sql_quote.	A DE H LA LI	NO NULOS
{% date_start date_filter_name %}	La fecha de inicio de un filtro de fecha que solicitas con date_filter_name Consulta la sección Uso de date_start y date_end para obtener más información.	S	2017-01-01
{% date_end date_filter_name %}	La fecha de finalización en un filtro de fechas que solicita con date_filter_name. Consulta la sección Uso de date_start y date_end para obtener más información.	S	2017-01-01
{% condition filter_name %} sql_or_lookml_reference {% endcondition %}	El valor del filtro que solicitas con filter_name aplicado a sql_or_lookml_reference como SQL. Esta variable se usa con filtros con plantilla y uniones condicionales.	S	Consulta la página de documentación Filtros con plantilla y la sección Uniones condicionales de la página de documentación sql_on para ver ejemplos.
{% parameter parameter_name %}	El valor del filtro de parámetros que solicitas con parameter_name.	DE LA S	Consulta la página de documentación del parámetro parameter para ver ejemplos.
parameter_name._parameter_value	Incorpora el valor del filtro de parámetros que solicitas con parameter_name en una instrucción lógica.	DE H LA LI S	Consulta la página de documentación del parámetro parameter para obtener ejemplos y detalles importantes.
Atributos de usuario
_user_attributes['name_of_attribute']	El valor del atributo de usuario que solicitas con name_of_attribute para el usuario específico que ejecuta la consulta, si se usan atributos de usuario. La variable _user_attributes['name_of_attribute'] también se puede usar en la sintaxis de filtro avanzado.	A DE H LA LI S DV F	noreste (si, por ejemplo, el atributo de usuario era "región"). Consulte la página Prácticas recomendadas sobre cómo usar atributos de usuario para la inserción de nombres de tablas y esquemas dinámicos a fin de obtener un ejemplo adicional.
_localization['localization_key']	Muestra el valor asociado con una clave de localización que se define en el archivo de strings del modelo, según la configuración regional del usuario.	DV F	Consulta la página de documentación Localiza tu modelo de LookML para ver un ejemplo.
Objetos de LookML
_model._name	El nombre del modelo para este campo.	A DE H LA LI S	aspecto
_view._name	El nombre de la vista para este campo.	A DE H LA LI S	orders
_explore._name	El nombre de Explorar para este campo.	A DE H LA LI S	pedidos_artículos
_explore._dashboard_url	ADDED 22.12 La URL relativa para el panel actual.	H LI	/dashboards/5
_field._name	El nombre del campo en sí, en formato view_name.field_name.	A DE H LA LI S	orders.total_order_amount
Queries
_query._query_timezone	La zona horaria en la que se ejecutó la consulta.	A DE H LA LI S	America/Los_Angeles
view_name._in_query	Muestra true si algún campo de la vista se incluye en la consulta.	DE LA LI S	verdadero
view_name.field_name._in_query	Muestra true si el campo que solicitas con view_name.field_name aparece en la tabla de datos de consulta, se incluye en un filtro para una consulta o se incluye en una consulta a través del parámetro required_fields.	DE LA LI S	verdadero
view_name.field_name._is_selected	Muestra true si el campo que solicitas con view_name.field_name aparece en la tabla de datos de consulta.	DE LA LI S	verdadero
view_name.field_name._is_filtered	Muestra true si el campo que solicitas con view_name.field_name se incluye en un filtro para la consulta.	DE LA LI S	verdadero

Uso de date_start y date_end

Las variables líquidas date_start y date_end son muy útiles para los dialectos de la base de datos que particionan datos en varias tablas por fecha, como BigQuery. Ten en cuenta que debes usar la sintaxis de etiqueta {% date_start date_filter_name %} o {% date_end date_filter_name %}. No puedes usar la sintaxis de resultado {{ date_start date_filter_name }} o {{ date_end date_filter_name }}, aunque esta sintaxis se suele usar para generar texto.

Por ejemplo, puedes crear estos campos en 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 %} ;;
}

Si filtras un elemento Explorar en new_filter_test con el período del 1 de abril de 2022 al 25 de mayo de 2022, la dimensión filter_start se evaluaría como 1 de abril de 2022; el valor de filter_end se evaluaría como 25 de mayo de 2022.

Ten en cuenta lo siguiente sobre date_start y date_end:

• Si el usuario no filtra la consulta con el filtro que se especifica en la parte date_filter de la variable Liquid, {% date_start date_filter %} y {% date_end date_filter %} evaluarán a NULL.

• Si el usuario filtra la consulta con un rango abierto en el filtro que se especifica en la parte date_filter de la variable Liquid, el extremo abierto del rango se resolverá en NULL. Por ejemplo, con example, si en la pestaña Explorar un usuario establece new_filter_test en antes del 07-06-2022, el resultado de {% date_start date_filter %} será NULL, ya que el usuario especificó un rango que tiene una fecha de finalización, pero no una fecha de inicio. Si un usuario establece new_filter_test en after 2022-06-07, el resultado de {% date_end date_filter %} será NULL.

En cualquiera de estos casos en los que la salida de Liquid puede mostrar un resultado de NULL, asegúrate de incluir una función SQL en el parámetro sql para tener en cuenta los valores NULL, como IFNULL o COALESCE, según el dialecto de tu base de datos.

Consulta la página de prácticas recomendadas Cómo usar date_start y date_end a fin de obtener una explicación detallada sobre cómo usar las variables líquidas date_start y date_end para tratar con tablas particionadas por fecha.

Consulte la publicación de la Comunidad sobre el análisis flexible entre períodos de Analytic Block a fin de obtener un ejemplo del uso de date_start y date_end para el análisis flexible entre períodos.

Uso de _in_query, _is_selected y _is_filtered

Ten en cuenta que las variables _in_query, _is_selected y _is_filtered proporcionan un valor verdadero o falso, como se muestra en este ejemplo. Por lo tanto, es importante elegir el tipo adecuado de referencia de la variable Líquida.

Si deseas determinar si algo se incluye en tu consulta y luego insertar cierto texto basado en eso, debes usar un patrón como el siguiente:

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

Si deseas literalmente insertar la palabra "verdadero" o "falso", usa un patrón como el siguiente:

{{ view_name.field_name._in_query }}

Algunos dialectos de SQL no admiten las palabras literales "true" y "false". En ese caso, puedes agregar el filtro sql_boolean para obtener los valores verdaderos y falsos que necesitas:

{{ view_name.field_name._in_query | sql_boolean }}

Los mismos patrones se aplican a las variables _is_selected y _is_filtered.

Uso de variables líquidas con el parámetro label

Puedes usar variables líquidas en el parámetro label de un campo para cambiar su apariencia de forma dinámica en el selector de campos y en las visualizaciones. Consulta la sección tabla en esta página para ver qué variables líquidas funcionarán con el parámetro label.

Las variables líquidas funcionan con parámetros de etiqueta a nivel de campo, incluidos los parámetros label, view_label, group_label y group_item_label, pero no funcionarán con parámetros de etiquetas a nivel de modelo, Explorar, ver o referencia, o con la etiqueta como subparámetro de link.

Las siguientes variables se pueden usar con label para modificar el selector de campos, los encabezados de columnas en la sección de datos de Explorar y las visualizaciones:

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

Las otras variables líquidas marcadas con LA en la tabla anterior, como las que muestran un valor basado en un filtro (como _filters) o requieren que se ejecute una consulta antes de que se pueda determinar el valor de la variable (como in_query), no cambiarán el nombre del campo en el selector de campos. En esos casos, el nombre del campo solo se cambiará en la visualización resultante.

Cuando se usa la variable líquida parameter con label, label se pasa el valor del subparámetro value.

Uso de variables líquidas con el parámetro description

Puedes usar variables líquidas con el parámetro description para cambiar de forma dinámica la descripción de un campo. Esta descripción aparece cuando los usuarios colocan el cursor sobre el ícono de información del campo en el selector de campo, el nombre de columna del campo en la sección de datos de Explorar o el nombre de columna del campo en un gráfico de tabla. Consulta la tabla en la sección Definiciones de las variables líquidas de esta página para ver qué variables líquidas funcionan con el parámetro description.

Las variables líquidas funcionan con el parámetro description solo a nivel de campo. No funcionarán con el parámetro description a nivel de Explorar.

Las siguientes variables se pueden usar con description para modificar el selector de campos, la sección de datos de Explorar y el encabezado de columna en un gráfico de tablas:

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

Las otras variables líquidas marcadas con DE en la tabla anterior, como las variables líquidas que muestran un valor basado en un filtro (como _filters) o que requieren que una consulta se ejecute antes de que se pueda determinar el valor de la variable (como in_query), no cambiarán la descripción en el selector de campo ni en la sección de datos de Explorar. Estas variables líquidas solo afectarán la descripción que se muestra cuando un usuario se desplaza sobre el encabezado de la columna del campo en un gráfico de tabla.

Para ver ejemplos de cómo usar Liquid en el parámetro description, consulta la página de documentación del parámetro description.

Aspectos para tener en cuenta

Haz referencia a yesno campos

Para hacer referencia al valor de un campo yesno, este distingue entre mayúsculas y minúsculas. Usa Yes o No Por ejemplo:

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

Usa operadores lógicos con variables líquidas

Puedes usar los operadores lógicos and, or y not con variables líquidas. Los operadores lógicos en Liquid distinguen mayúsculas de minúsculas y deben escribirse en minúsculas. Por ejemplo:

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

Aparece el error "Variable no encontrada"

Es posible que veas este error en Liquid si usas {{ }} y {% %} al mismo tiempo, como se muestra a continuación:

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

En su lugar, haz esto:

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

Si utiliza un filtro con plantilla, verifique si está haciendo referencia a un nombre de tabla que no se unió a la tabla derivada.

Las convenciones de nombres pueden afectar la agrupación de consultas

Si hay un campo con el nombre value, este se incluirá en la cláusula GROUP BY de una consulta de exploración siempre que se haga referencia a la variable value líquida en otro campo de la misma vista.

Por ejemplo:

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
}

Esto generará el siguiente SQL cuando solo se seleccione id en Explorar:

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

Para evitar este comportamiento de agrupación, asegúrate de definir el alcance de la variable value con el nombre del campo para hacer referencia a él de manera explícita:

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

El uso de _filters['view_name.field_name'] en una tabla derivada requiere sql_quote

Cuando defines una tabla derivada basada en SQL, si usas la variable líquida _filters['view_name.field_name'] en la que el valor se renderiza en SQL y el filtro muestra un valor de string, debes agregar comillas simples alrededor del resultado. Para ello, incluye el filtro de líquido sql_quote.

Por ejemplo, si usas alguna de estas variables líquidas en el parámetro sql de un parámetro derived_table, haz lo siguiente:

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

o

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

Puedes agregar el filtro de líquido | sql_quote a la declaración de la variable líquida:

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

y

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

A continuación, se muestra un ejemplo de tabla derivada que usa 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
      ;;
  }

El campo city es una string que se enviará a SQL, por lo que se necesita el filtro líquido sql_quote para asegurarse de que el SQL de salida esté entre comillas simples. En la exploración resultante, cuando un usuario especifica el nombre de una ciudad como un filtro, Looker encierra la string del nombre de la ciudad entre comillas. Looker envía este SQL a la base de datos si un usuario filtra la consulta Explorar en el valor de ciudad New York:

WHERE
    users.city = 'New York'

Si usas la variable líquida _filters['view_name.field_name'] para un campo de string en una tabla derivada en la que el valor se renderiza en SQL, recibirás la siguiente advertencia de LookML si no agregas | sql_quote a la variable líquida:

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

También puedes usar sql_quote con esta sintaxis para citar varios valores en un arreglo:

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

Aquí tienes un ejemplo en el que se usa la salida líquida como entrada para una instrucción IN:

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

Con esta sintaxis, el resultado líquido tendrá comillas alrededor de cada valor individual ('value1','value2','value3'), en lugar de comillas alrededor de la lista completa ('value1, value2, value3').

Las variables líquidas en las medidas agregadas afectan la agrupación

Cuando se usa la sintaxis {{ view_name.field_name._value }} o {{ field_name._value }} en los parámetros link o html de una medida para hacer referencia a un valor de otro campo, Looker extrae ese campo a la consulta de SQL para tomar el valor del campo. Debido a esto, Liquid puede afectar la forma en que se generan las consultas de SQL y la cantidad de columnas que usa la cláusula GROUP BY, lo que puede causar un comportamiento inesperado cuando trabajas con medidas agregadas, como las de type: count.

Por ejemplo, supongamos que tienes las dos medidas siguientes:

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

Cuando generas una consulta con la medida count_without_liquid, obtienes los siguientes resultados:

En este caso, la consulta muestra un solo recuento para cada mes. A continuación, se muestra el SQL que se genera para los resultados anteriores:

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

Sin embargo, cuando generas una consulta con la medida count_with_liquid, obtienes los siguientes resultados:

En este ejemplo, se muestra que, en lugar de un recuento para cada mes de la consulta, recibes un recuento por cada mes y por cada estado. Esto se debe a que, en el SQL generado, se agregó el campo status a la consulta para que se pueda recuperar su valor. Y, como se agregó a la consulta, también se agregó a la cláusula 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

Una opción para evitar que esto suceda es usar la función row[] con la variable Liquid, que extrae su valor de los resultados procesados en el navegador y, por lo tanto, no agrega el campo al que se hace referencia en la consulta de 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'] }}"
  }

Cuando uses esta sintaxis, ten en cuenta que el parámetro link solo funciona si el campo está seleccionado o incluido en la consulta por otros medios.

En resumen, el uso de la sintaxis row[] no hará que el campo se agregue a la consulta como lo hace {{ field_name._value }}. La etiqueta dinámica hará que el vínculo no tenga ninguna etiqueta si el campo no está disponible, lo que hace que el vínculo desaparezca del menú de vínculos.