Filtros con plantilla y parámetros Liquid

Este es un tema avanzado para el que se da por sentado que tienes un buen conocimiento preexistente de SQL y LookML.

Looker proporciona automáticamente a los usuarios la capacidad de manipular sus consultas mediante la creación de filtros, que se basan en dimensiones y medidas. Si bien este método sencillo satisface muchos casos de uso, no puede habilitar todas las necesidades analíticas. Los filtros con plantilla y los parámetros Liquid amplían enormemente los posibles casos de uso que puedes admitir.

Desde la perspectiva de SQL, las dimensiones y medidas solo pueden alterar las cláusulas WHERE o HAVING más externas de tu consulta. Sin embargo, puede que quieras permitir que los usuarios manipulen otras partes de SQL. Ajustar parte de una tabla derivada, ajustar qué tabla de base de datos se consulta o crear dimensiones y filtros multipropósito son solo algunas de las funciones que puedes habilitar con los filtros con plantillas y los parámetros Liquid.

Los filtros basados en plantillas y los parámetros Liquid usan el lenguaje de plantillas Liquid para insertar entradas del usuario en consultas en SQL. Primero, usa un parámetro de LookML para crear un campo con el que los usuarios puedan interactuar. A continuación, usarás una variable Liquid para inyectar la entrada del usuario en las consultas SQL.

Ejemplos

Veamos algunos ejemplos para demostrar el valor de los filtros con plantilla y los parámetros Liquid.

Cómo crear una tabla derivada dinámica con un filtro con plantilla

Considera el uso de una tabla derivada que calcula el gasto total de un cliente, dentro de la región nordeste:

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,                        -- Can be made a dimension
        SUM(sale_price) AS lifetime_spend   -- Can be made a dimension
      FROM
        order
      WHERE
        region = 'northeast'                -- Can NOT be made a dimension
      GROUP BY 1
    ;;
  }
}

En esta consulta, puedes crear dimensiones a partir de customer_id y lifetime_spend. Sin embargo, supongamos que quieres que el usuario pueda especificar el region, en lugar de codificarlo como "northeast". El elemento region no se puede exponer como una dimensión, por lo que el usuario no puede filtrarlo con normalidad.

Una opción sería usar un filtro basado en plantillas, que se vería de la siguiente manera:

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        SUM(sale_price) AS lifetime_spend
      FROM
        order
      WHERE
        {% condition order_region %} order.region {% endcondition %}
      GROUP BY 1
    ;;
  }

  filter: order_region {
    type: string
  }
}

Más abajo puedes obtener instrucciones paso a paso.

Si una tabla derivada usa un filtro con plantilla, no puedes hacer que la tabla sea persistente.

Cómo realizar una medición dinámica con un parámetro Liquid

Considera una medición filtrada que sume la cantidad de pantalones vendidos:

measure: pants_count {
  filters: [category: "pants"]
}

Esto es sencillo, pero si hubiera decenas de categorías, sería tedioso crear una medida para cada una. Además, puede desordenar la experiencia de Explorar para los usuarios.

Una alternativa sería crear una medición dinámica como la siguiente:

measure: category_count {
  type: sum
  sql:
    CASE
      WHEN ${category} = '{% parameter category_to_count %}'
      THEN 1
      ELSE 0
    END
  ;;
}

parameter: category_to_count {
  type: string
}

Más abajo puedes obtener instrucciones paso a paso.

Uso básico

Paso uno: Crea algo con lo que el usuario interactúe

  • Para los filtros con plantilla, agrega un filter.
  • Para los parámetros Liquid, agrega un parameter.

En cualquier caso, estos campos se mostrarán al usuario en la sección Campos de solo filtro del selector de campos.

Los campos filter y parameter pueden aceptar una serie de parámetros secundarios, lo que te permite personalizar la forma en que funcionan. Consulta la página de documentación Parámetros de campo para obtener una lista completa. Hay dos opciones que se mencionan de forma especial para los campos parameter.

Primero, los campos parameter pueden tener un tipo especial llamado sin comillas:

parameter: table_name {
  type: unquoted
}

Este tipo permite insertar valores en SQL sin encerrarse entre comillas, como lo haría una cadena. Esto puede ser útil cuando necesitas insertar valores de SQL, como nombres de tablas.

En segundo lugar, los campos parameter tienen una opción llamada valores permitidos, que te permiten asociar un nombre fácil de usar al valor que deseas insertar. Por ejemplo:

  parameter: sale_price_metric_picker {
    description: "Use with the Sale Price Metric measure"
    type: unquoted
    allowed_value: {
      label: "Total Sale Price"
      value: "SUM"
    }
    allowed_value: {
      label: "Average Sale Price"
      value: "AVG"
    }
    allowed_value: {
      label: "Maximum Sale Price"
      value: "MAX"
    }
    allowed_value: {
      label: "Minimum Sale Price"
      value: "MIN"
    }
  }

Paso dos: Aplica la entrada del usuario

El segundo paso es usar Liquid para agregar el filtro con plantilla o el parámetro Liquid como desees.

Filtros basados en plantillas

La sintaxis de los filtros con plantilla se desglosa de la siguiente manera:

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
  • Las palabras condition y endcondition no cambian nunca.
  • Reemplaza filter_name por el nombre del filtro que creaste en el primer paso. Si no creaste un campo de solo filtro, también puedes utilizar una dimensión.
  • Reemplaza sql_or_lookml_reference por el SQL o LookML que debe establecerse como “igual” a la entrada del usuario (obtén más detalles a continuación). Si usas LookML, usa la sintaxis ${view_name.field_name} de LookML.

En el ejemplo anterior, usamos lo siguiente:

{% condition order_region %} order.region {% endcondition %}

Es importante comprender la interacción entre las etiquetas de Liquid y el SQL que escribes entre ellas. Las etiquetas de filtro con plantilla siempre se transforman en una expresión lógica. Por ejemplo, si el usuario ingresó “Nordeste” en el filtro order_region, Looker convertirá estas etiquetas en order.region = 'Northeast'. En otras palabras, Looker entiende las entradas del usuario y genera la expresión lógica adecuada.

Este suele ser un punto de confusión entre los desarrolladores de Looker. Los filtros con plantilla siempre dan como resultado una expresión lógica de algún tipo y no el valor individual que ingresa un usuario.

Debido a que los filtros con plantillas muestran una expresión lógica, puedes usarlos con otros operadores lógicos y expresiones lógicas que sean válidas en la instrucción WHERE de SQL. Con el ejemplo anterior, si quieres mostrar todos los valores excepto la región que seleccionó el usuario, puedes usar lo siguiente en la sentencia WHERE:

NOT ({% condition order_region %} order.region {% endcondition %})

También es válido usar un campo de LookML como condición del filtro. Cualquier filtro aplicado directamente al campo de LookML determinará el valor de la declaración WHERE:

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        SUM(sale_price) AS lifetime_spend
      FROM
        order
      WHERE
        {% condition region %} order.region {% endcondition %}
      GROUP BY 1
    ;;
  }

  dimension: region {
    type: string
    sql: ${TABLE}.region ;;
}

Parámetros líquidos

La sintaxis de los parámetros Liquid se desglosa de la siguiente manera:

{% parameter parameter_name %}
  • La palabra parameter nunca cambia.
  • Reemplaza parameter_name por el nombre del parameter que creaste en el primer paso.

Por ejemplo, para aplicar la entrada del campo parameter en el paso uno anterior, puedes crear una medición como la siguiente:

  measure: sale_price_metric {
    description: "Use with the Sale Price Metric Picker filter-only field"
    type: number
    label_from_parameter: sale_price_metric_picker
    sql: {% parameter sale_price_metric_picker %}(${sale_price}) ;;
    value_format_name: usd
  }

Elige entre filtros con plantillas y parámetros Liquid

Aunque los filtros con plantillas y los parámetros Liquid son similares, existe una diferencia importante entre ellos:

  • Los parámetros líquidos insertan entradas del usuario directamente (o mediante los valores que definas con valores permitidos).
  • Los filtros con plantillas insertan valores como sentencias lógicas, como se describió anteriormente.

En situaciones en las que desees ofrecer a los usuarios entradas más flexibles (como con varios tipos de períodos o búsquedas de strings), intenta utilizar filtros con plantillas cuando sea posible. Looker puede interpretar las entradas del usuario y escribir el SQL adecuado en segundo plano. Esto evita que tengas que considerar todos los tipos posibles de entradas del usuario.

En situaciones en las que no se puede insertar una instrucción lógica o en las que conoces un conjunto limitado de opciones que el usuario podría ingresar, usa los parámetros Liquid.