filtro_condicional

Uso

explore: explore_name {
conditionally_filter: {
filtros: [field_name: "filter expression", field_name: "filter expression", ...]
a menos: [field_name,]

Jerarquía Archivo del modelo explore conditionally_filter

Valor predeterminado Ninguna Acepta Una o más especificaciones de filtro de un nombre de campo y una expresión de filtro de Looker, más una lista de uno o más nombres de campo en la sección unless

Definición

El parámetro conditionally_filter te permite definir un conjunto de filtros predeterminados que los usuarios pueden anular si aplican al menos un filtro de una segunda lista que definas.

Por lo general, este parámetro se usa para evitar que los usuarios creen de forma accidental consultas muy grandes que pueden ser demasiado costosas para ejecutarse en tu base de datos. Por ejemplo, puedes obligar a un usuario a limitar su búsqueda a la semana anterior, a menos que haya solicitado explícitamente un período más largo.

Los filtros que se aplicaron en conditionally_filter se muestran al usuario después de que ejecuta su consulta. Si bien los usuarios pueden cambiar el value predeterminado que estableces, no pueden quitar por completo el filtro, a menos que apliquen al menos uno de los filtros que especifiques en el subparámetro unless.

Los nombres de los campos que usas pueden ser dimension o measure.

Para hacer referencia a una dimensión o medida que es parte de una vista unida en lugar de parte de esta exploración, usa view_name.field_name.

Ejemplos

Considera el siguiente ejemplo:

explore: order {
  conditionally_filter: {
    filters: [id: "123", customer.id: "678,789"]
    unless: [date]
  }

  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

En este caso, el filtro id hace referencia al campo id de Explorar llamado order. El filtro customer.id hace referencia al campo id de la vista llamado customer. Se aplicarán ambos filtros, a menos que el usuario establezca una fecha del pedido en la IU de Explorar. En este ejemplo, también se demuestra que puedes requerir varios filtros.

El valor predeterminado que especifiques puede aceptar estos tipos de expresiones.

También puede obligar al usuario a usar un filtro de ID de pedido (con un valor predeterminado de "123" que puede cambiar) a menos que aplique un filtro de Fecha de pedido:

explore: order {
  conditionally_filter: {
    filters: [id: "123"]
    unless: [date]
  }
}

De manera alternativa, fuerza al usuario a usar un filtro de ID de pedido (con un valor predeterminado de "123" o "234" que pueden cambiar) a menos que apliquen un filtro de Fecha de pedido o Hora del pedido:

explore: order {
  conditionally_filter: {
    filters: [id: "123,234"]
    unless: [date, time]
  }
}

O bien, obligue al usuario a usar un filtro de ID de pedido (valor predeterminado de "123") y un filtro de Ciudad del cliente (con el valor predeterminado de "Chicago"), a menos que apliquen un filtro de Fecha de pedido o Fecha del cliente:

explore: order {
  conditionally_filter: {
    filters: [id: "123", customer.city: "Chicago"]
    unless: [date, customer.date]
  }

  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Desafíos habituales

Un usuario no puede quitar todos los filtros cuando se usa conditionally_filter

No se puede ejecutar una consulta sin ningún filtro cuando se usa conditionally_filter. Un usuario debe usar los filtros condicionales que especifiques o sus propios filtros de la lista unless.

conditionally_filter con una dimensión de type: time en un grupo coloca las otras dimensiones del grupo en el subparámetro unless.

Si el field que especifica en conditionally_filter es una dimensión basada en el tiempo que forma parte de un grupo de dimensiones, Looker tratará todas las demás dimensiones de ese grupo como si estuvieran sujetas a un subparámetro unless para ese filtro condicional, incluso si no incluye un subparámetro unless.

Los dos bloques siguientes de LookML se interpretan de manera idéntica. Aquí, se aplica conditionally_filter a una dimensión basada en el tiempo event_date que forma parte del grupo de dimensiones event. No se especificaron condiciones unless, pero Looker tratará las otras dimensiones del grupo event como si se hubieran especificado con el subparámetro unless.

LookML block 1:

explore: logs {
  # Make sure there is always a filter on event_date, event_week, event_month or event_year
  # Default to the last complete day of data
  conditionally_filter: {
    filters: [logs.event_date: "1 days ago for 1 day"]
  }

view: logs {
  # Combine the partition date filters and the time filters into a single field group.
  dimension_group: event {
    type: time
    timeframes: [date,week,month,year]
    sql: _PARTITIONTIME ;;
  }
}

LookML block 2:

explore: logs {
  # Make sure there is always a filter on event_date, event_week, event_month or event_year
  # Default to the last complete day of data
  conditionally_filter: {
    filters: [logs.event_date: "1 days ago for 1 day"]
    unless: [event_week, event_month, event_year]
  }

view: logs {
  # Combine the partition date filters and the time filters into a single field group.
  dimension_group: event {
    type: time
    timeframes: [date,week,month,year]
    sql: _PARTITIONTIME ;;
  }
}

Looker interpreta los dos bloques LookML de la misma manera, aunque solo el segundo bloque LookML aplique explícitamente el subparámetro unless a las otras dimensiones del grupo event.

Qué debes saber

Hay un método para aplicar conditionally_filter a un subconjunto de usuarios

Para aplicar un filtro condicional a algunos usuarios y no a otros, puede usar los permisos del modelo. Debes crear dos modelos: uno en el que se use conditionally_filter y otro en el que no se usa. Luego, puedes otorgar acceso a los modelos adecuados por usuario.

Si quieres usar conditionally_filter sin unless, usa always_filter

Para obligar a los usuarios a usar un conjunto de filtros específico, sin importar qué lo haga, pero permitirles cambiar el valor predeterminado, usa always_filter en su lugar.

Si deseas filtros que no se puedan modificar, considera sql_always_where

Si quieres que Explorar tenga filtros iguales para todos y no permitas que los usuarios cambien el valor del filtro, usa sql_always_where.

Si deseas filtros específicos del usuario que no se puedan cambiar, considera access_filter

Si quieres que Explorar tenga filtros específicos para cada usuario, pero que no se puedan quitar ni cambiar, usa access_filter.