Filtros con plantillas y parámetros de Liquid

Este es un tema avanzado dirigido a usuarios que tienen un buen conocimiento previo 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 mediciones. Si bien este método satisface muchos casos de uso, no puede satisfacer todas las necesidades analíticas. Los filtros basados en plantillas y los parámetros de Liquid amplían en gran medida los casos de uso posibles que puedes admitir.

Desde una perspectiva de SQL, las dimensiones y las mediciones solo pueden modificar las cláusulas WHERE o HAVING más externas de tu consulta. Sin embargo, es posible 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 de usos múltiples son solo algunas de las funciones que puedes habilitar con filtros basados en plantillas y parámetros de Liquid.

Advertencia: La persistencia no es compatible con las tablas derivadas que usan filtros basados en plantillas o 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, usas un parámetro de LookML para crear un campo con el que los usuarios puedan interactuar. Luego, usas una variable de Liquid para insertar 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.

Cómo crear una tabla derivada dinámica con un filtro basado en plantillas

Considera una tabla derivada que calcula el gasto del ciclo de vida de un cliente en la región 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, puedes crear dimensiones a partir de customer_id y lifetime_spend. Sin embargo, supongamos que quieres que el usuario pueda especificar la region, en lugar de codificarla de forma rígida como "northeast". La region no se puede exponer como una dimensión y, por lo tanto, el usuario no puede filtrar en ella de forma normal.

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

Obtén más información en la sección Uso básico para obtener instrucciones paso a paso.

Nota: Si una tabla derivada usa un filtro basado en plantillas, no puedes hacer que la tabla sea persistente.

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

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

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

Esto es sencillo, pero si hubiera docenas de categorías, sería tedioso crear una medición 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 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
}

Obtén más información en la sección Uso básico para obtener instrucciones paso a paso.

Uso básico

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

• Para los filtros basados en plantillas, agrega un filter.
• Para los parámetros de Liquid, agrega un parameter.

En cualquier caso, estos campos aparecerán para el usuario en la sección Campos solo de filtro 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 página de documentación Parámetros de campo para obtener una lista completa. Hay dos opciones que merecen una mención especial para los campos parameter.

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

parameter: table_name {
  type: unquoted
}

Este tipo permite que los valores se inserten en SQL sin estar entre comillas, como lo estarí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 permite asociar un nombre fácil de usar con el 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 basado en plantillas o el parámetro de Liquid según lo desees.

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.
• Reemplaza filter_name por el nombre del filtro que creaste en el primer paso. También puedes usar una dimensión si no creaste un campo solo de filtro.
• Reemplaza sql_or_lookml_reference por el SQL o LookML que se debe establecer como "igual" a la entrada del usuario (esto se explica con más detalle más adelante en esta sección). Si usas LookML, usa la sintaxis de LookML ${view_name.field_name}.

En el ejemplo anterior, Cómo crear una tabla derivada dinámica con un filtro basado en plantillas, 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 las etiquetas. Estas etiquetas de filtro basadas en plantillas siempre se transforman en una expresión lógica. Por ejemplo, si el usuario ingresó "Northeast" en el filtro order_region, Looker convertiría estas etiquetas en lo siguiente:

order.region = 'Northeast'

En otras palabras, Looker interpreta la entrada del usuario y genera la expresión lógica adecuada.

Nota: A menudo, este es un punto de confusión entre los desarrolladores de Looker. Los filtros basados en plantillas 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 basados en plantillas muestran una expresión lógica, puedes usarlos con otros operadores lógicos y expresiones lógicas que sean válidos en la instrucción WHERE de SQL. Con el ejemplo anterior, si deseas mostrar todos los valores excepto la región que seleccionó 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. Cualquier filtro que se aplique directamente al campo de LookML determinará 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.
• Reemplaza parameter_name por el nombre parameter que creaste en el primer paso.

Por ejemplo, para aplicar la entrada del campo parameter en el paso uno, puedes crear una medición 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
  }

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

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

• Los parámetros de Liquid insertan la entrada del usuario directamente (o usan los valores que defines con valores permitidos).
• Los filtros basados en plantillas insertan valores como instrucciones lógicas, como se describe en la sección Filtros basados en plantillas.

En situaciones en las que deseas ofrecer a los usuarios una entrada más flexible (como con varios tipos de períodos o búsquedas de cadenas), intenta usar filtros basados en plantillas cuando sea posible. Looker puede interpretar la entrada del usuario y escribir el SQL adecuado en segundo plano. Esto evita que tengas que tener en cuenta todos los tipos posibles de entrada del 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 ingresar, usa parámetros de Liquid.