sql_always_where

Uso

explore: explore_name {
sql_always_where: ${created_date} >= '2017-01-01' ;
}

Jerarquía Archivo del modelo explore sql_always_where

Valor predeterminado Ninguna Acepta Una condición WHERE de SQL que usa los nombres de las dimensiones o las columnas de SQL Reglas especiales Si haces referencia a un nombre de columna de SQL en sql_always_where que es parte de una vista unida en lugar de parte de Explorar, es importante usar el parámetro always_join, o bien hacer referencia a un nombre de campo.

Definición

sql_always_where te permite aplicar una restricción de consulta que los usuarios no pueden cambiar. La restricción se insertará en la cláusula WHERE del SQL subyacente que Looker generará para todas las consultas en la Explorar donde se usa sql_always_where. Además de las consultas que ejecuten los usuarios, la restricción se aplicará a los paneles, la apariencia incorporada y los aspectos programados que dependan de esa exploración.

La condición se puede escribir en SQL puro con los nombres de columna y tabla reales 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 diferente de Looker o a una tabla derivada Ten en cuenta que SQL_TABLE_NAME en esta referencia es una string literal; no necesitas reemplazarla por nada.
• ${view_name.field_name}, que hace referencia a un campo de Looker Usar este método es mejor que consultar las columnas de SQL directamente, ya que Looker puede incluir automáticamente cualquier unión necesaria.

No se muestra una condición sql_always_where al usuario, a menos que mire el SQL subyacente de las consultas que crea.

Ejemplos

Impedir que los usuarios vean los pedidos antes del 1 de enero de 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 de los clientes de Periaptly Corporation:

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

Impedir que los usuarios consulten los pedidos de Periaptly Corporation:

explore: order {
  sql_always_where: ${customer.name} <> 'Periaptly 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 es parte de una vista unida, en lugar de Explorar, es importante usar el parámetro always_join. Considera el siguiente ejemplo:

explore: order {
  sql_always_where: customer.name <> 'Periaptly 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 order Explorar. Dado que sql_always_where se aplicará a cada consulta, es importante que customer también se una a cada consulta.

Cuando Looker genera SQL para una consulta, intenta crear el SQL más limpio posible y solo usará las uniones necesarias para los campos que un usuario selecciona. En este caso, Looker solo se unirá a customer si un usuario selecciona un campo de cliente. Con always_join, puedes forzar la unión para que ocurra sin importar lo que ocurra.

Si, en lugar de sql_always_where: customer.name <> 'Periaptly Corporation', usaras sql_always_where: ${customer.name} <> 'Periaptly Corporation', Looker sería lo suficientemente inteligente para hacer la unión de customer sin que debas usar always_join. Por este motivo, te recomendamos que uses referencias de campo de Looker en lugar de referencias de SQL sin procesar cuando sea posible.

Usa solo una sql_always_where por Explorar

Solo debes tener 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.

Qué debes saber

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

Existe 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 WHERE.

Si quieres filtros que un usuario puede cambiar, pero no quitar, considera always_filter

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

Si deseas filtros específicos de usuarios que no se puedan cambiar, considera access_filter

Si quieres que Explorar tenga filtros específicos para cada usuario y que no se pueda cambiar de ninguna manera, puedes usar access_filter.