sql_always_where

Uso

explore: explore_name {
  sql_always_where: ${created_date} >= '2017-01-01' ;;
}
Jerarquía
explore
sql_always_where
Valor predeterminado
Ninguno

Acepta
Condición WHERE de SQL que usa nombres de dimensiones o nombres de columnas de SQL

Reglas especiales
Si haces referencia a un nombre de columna de SQL en sql_always_where que forma parte de una vista combinada en lugar de formar parte de la Exploración, es importante que uses el parámetro always_join o que hagas referencia a un nombre de campo.

Definición

sql_always_where te permite aplicar una restricción de búsqueda que los usuarios no pueden cambiar. La restricción se insertará en la cláusula WHERE del SQL subyacente que genera Looker para todas las consultas en la Exploración en la que se usa sql_always_where. Además de las consultas que ejecutan los usuarios humanos, la restricción se aplicará a los paneles, las vistas planificadas y la información incorporada que dependa de esa exploración.

La condición se puede escribir en SQL puro, con los nombres reales de las tablas y las columnas de tu base de datos. También puede usar referencias de Looker, como las siguientes:

  • ${view_name.SQL_TABLE_NAME}, que hace referencia a una vista de Looker diferente o a una tabla derivada Ten en cuenta que SQL_TABLE_NAME en esta referencia es una cadena literal, por lo que no necesitas reemplazarla con nada.
  • ${view_name.field_name}, que hace referencia a un campo de Looker. Usar este método es mejor que hacer referencia a las columnas de SQL directamente, ya que Looker puede incluir automáticamente cualquier unión necesaria.

Una condición sql_always_where no se muestra al usuario, a menos que este examine el SQL subyacente de las consultas que crea.

Ejemplos

Impedir que los usuarios vean pedidos anteriores al 01-01-2012:

# Using Looker references
explore: order {
  sql_always_where: ${created_date} >= '2012-01-01' ;;
}

# Using raw SQL
explore: order {
  sql_always_where: DATE(created_time) >= '2012-01-01' ;;
}

Impedir que los usuarios vean la información del cliente de Altostrat Corporation:

explore: customer {
  sql_always_where: ${name} <> 'Altostrat Corporation' ;;
}

Para evitar que los usuarios vean los pedidos de Altostrat Corporation, haz lo siguiente:

explore: order {
  sql_always_where: ${customer.name} <> 'Altostrat Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Desafíos habituales

Si usas SQL sin procesar, es posible que debas usar always_join.

Si haces referencia a un nombre de columna de SQL en sql_always_where que forma parte de una vista combinada, en lugar de la función Explorar, es importante que uses el parámetro always_join. Considera el siguiente ejemplo:

explore: order {
  sql_always_where: customer.name <> 'Altostrat Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

En este caso, sql_always_where hace referencia a una columna de la vista customer unida, en lugar de la exploración order. Dado que sql_always_where se aplicará a cada consulta, es importante que customer también se una en cada consulta.

Cuando Looker genera SQL para una consulta, intenta crear el SQL más limpio posible y solo usará las uniones que sean necesarias para los campos que seleccione un usuario. En este caso, Looker solo uniría customer si un usuario seleccionara un campo de cliente. Si usas always_join, puedes forzar la unión sin importar qué suceda.

Si, en lugar de sql_always_where: customer.name <> 'Altostrat Corporation', usaras sql_always_where: ${customer.name} <> 'Altostrat Corporation', Looker sería lo suficientemente inteligente como para realizar la unión customer sin necesidad de que uses always_join. Por este motivo, te recomendamos que uses referencias de campos de Looker en lugar de referencias de SQL sin procesar siempre que sea posible.

Solo se puede usar un sql_always_where por exploración.

Solo debe haber un sql_always_where en una definición de explore. Coloca todo el comportamiento deseado en un solo sql_always_where usando AND y OR según sea necesario.

Información importante

Existe un parámetro similar para la cláusula HAVING de SQL.

Hay un parámetro muy similar a sql_always_where llamado sql_always_having que funciona de la misma manera, pero aplica condiciones a la cláusula HAVING en lugar de a la cláusula WHERE.

Si quieres filtros que un usuario pueda cambiar, pero no quitar, considera usar always_filter.

Si quieres obligar a los usuarios a usar un conjunto específico de filtros, pero el valor predeterminado se puede cambiar, prueba con always_filter.

Si quieres filtros específicos del usuario que no se puedan cambiar, considera usar access_filter.

Si deseas que una exploración tenga filtros específicos para cada usuario y que no se puedan cambiar de ninguna manera, puedes usar access_filter.

Cuando un Explore incluye sql_always_where, el valor predeterminado de full_suggestions cambia a yes.

Cuando un Explorar incluye el parámetro sql_always_where, el valor predeterminado de full_suggestions cambia a yes. Esto hace que la consulta de sugerencias se ejecute con la lógica de Explorar, lo que significa que se aplicará sql_always_where para reducir las sugerencias que se devuelvan, lo que limitará la lista de sugerencias solo a los datos a los que el usuario debe tener acceso.

Si estableces full_suggestions en no de forma manual, no se ejecutará la consulta de sugerencias de filtros.