Filtros basados en plantillas y parámetros de Liquid

Este es un tema avanzado dirigido a usuarios que ya tienen un buen conocimiento de SQL y LookML.

Looker ofrece automáticamente a los usuarios la posibilidad de manipular sus consultas creando filtros basados en dimensiones y medidas. Aunque este método se adapta a muchos casos prácticos, no puede satisfacer todas las necesidades analíticas. Los filtros basados en plantillas y los parámetros de Liquid amplían enormemente los casos prácticos que puedes admitir.

Desde el punto de vista de SQL, las dimensiones y las medidas solo pueden modificar las cláusulas WHERE o HAVING más externas de la consulta. Sin embargo, puede que quieras permitir que los usuarios manipulen otras partes de SQL. Ajustar una parte de una tabla derivada, modificar la tabla de la base de datos que se consulta o crear dimensiones y filtros polivalentes son solo algunas de las funciones que puedes habilitar con filtros basados en plantillas y parámetros de Liquid.

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

Ejemplos

Veamos algunos ejemplos para demostrar el valor de los filtros basados en plantillas y los parámetros de Liquid.

Crear una tabla derivada dinámica con un filtro basado en una plantilla

Supongamos que tienes una tabla derivada que calcula el gasto total de un cliente en la región del noreste:

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, puede 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 region no se puede exponer como dimensión, por lo que el usuario no puede filtrar por él de forma normal.

Una opción sería usar un filtro basado en una plantilla, que tendría este aspecto:

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

Para ver instrucciones detalladas, consulta la sección Uso básico.

Crear una medida dinámica con un parámetro de Liquid

Considera una medida filtrada que sume el número de pantalones vendidos:

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

Es un proceso sencillo, pero si hubiera docenas de categorías, sería tedioso crear una medida para cada una. Además, puede sobrecargar la experiencia de Explorar de los usuarios.

Otra opción sería crear una medida dinámica como esta:

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

parameter: category_to_count {
  type: string
}

Consulta más información en la sección Uso básico para ver instrucciones detalladas.

Uso básico

Paso 1: Crea algo con lo que el usuario pueda interactuar

• En el caso de los filtros basados en plantillas, añade un filter.
• En el caso de los parámetros de Liquid, añade un parameter.

En ambos casos, estos campos aparecerán en la sección Campos solo para filtros del selector de campos.

Los campos filter y parameter pueden aceptar una serie de parámetros secundarios, lo que te permite personalizar su funcionamiento. Consulta la lista completa en la página de documentación Parámetros de campo. Hay dos opciones que merecen una mención especial en el caso de los campos parameter.

En primer lugar, los campos parameter pueden tener un tipo especial llamado sin comillas:

parameter: table_name {
  type: unquoted
}

Este tipo permite insertar valores en SQL sin que estén entre comillas, como ocurriría con una cadena. Esto puede ser útil si necesitas insertar valores SQL, como nombres de tablas.

En segundo lugar, los campos parameter tienen una opción llamada valores permitidos que te permite asociar un nombre fácil de usar con el valor que quieras 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 2: Aplica la entrada del usuario

El segundo paso es usar Liquid para añadir el filtro de plantilla o el parámetro de Liquid que quieras.

Filtros basados en plantillas

La sintaxis de los filtros basados en plantillas se desglosa de la siguiente manera:

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}

• Las palabras condition y endcondition nunca cambian.
• Sustituye filter_name por el nombre del filtro que has creado en el primer paso. También puede usar una dimensión si no ha creado un campo de solo filtro.
• Sustituye sql_or_lookml_reference por el código SQL o LookML que debe ser igual a la entrada del usuario (se explica con más detalle más adelante en esta sección). Si usas LookML, utiliza la ${view_name.field_name} sintaxis de LookML.

En el ejemplo anterior, Crear una tabla derivada dinámica con un filtro basado en una plantilla, hemos usado lo siguiente:

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

Es importante entender la interacción entre las etiquetas Liquid y el código SQL que escribas entre ellas. Estas etiquetas de filtro basadas en plantillas siempre se transforman en una expresión lógica. Por ejemplo, si el usuario introduce "Noreste" en el filtro order_region, Looker convertirá estas etiquetas en lo siguiente:

order.region = 'Northeast'

Es decir, Looker interpreta la entrada del usuario y genera la expresión lógica adecuada.

Como los filtros basados en plantillas devuelven una expresión lógica, puedes usarlos con otros operadores y expresiones lógicas válidos en la instrucción SQL WHERE. En el ejemplo anterior, si quieres devolver todos los valores excepto la región que ha seleccionado el usuario, puedes usar lo siguiente en la instrucción WHERE:

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

También es válido usar un campo de LookML como condición de filtro. Los filtros que se apliquen directamente al campo de LookML determinarán el valor de la instrucció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 de Liquid

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

{% parameter parameter_name %}

• La palabra parameter nunca cambia.
• Sustituye parameter_name por el nombre de parameter que has creado en el primer paso.

Por ejemplo, para aplicar la entrada del campo parameter del paso 1, puedes crear una medida como esta:

  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
  }

Elegir entre filtros basados en plantillas y parámetros de Liquid

Aunque los filtros basados en plantillas y los parámetros de Liquid son similares, hay una diferencia importante entre ellos:

• Los parámetros de Liquid insertan directamente los datos introducidos por el usuario (o los valores que definas con valores permitidos).
• Los filtros basados en plantillas insertan valores como instrucciones lógicas, tal como se describe en la sección Filtros basados en plantillas.

En los casos en los que quieras ofrecer a los usuarios una entrada más flexible (como con varios tipos de intervalos de fechas o búsquedas de cadenas), intenta usar filtros basados en plantillas siempre que sea posible. Looker puede interpretar la entrada del usuario y escribir el código SQL adecuado en segundo plano. De esta forma, no tendrás que tener en cuenta todos los tipos posibles de entrada de usuario.

En situaciones en las que no se puede insertar una instrucción lógica o en las que conoces un conjunto finito de opciones que el usuario puede introducir, usa parámetros de Liquid.