sql_always_have

Uso

explore: explore_name {
sql_always_have: ${count} >= 100 ;;
}

Jerarquía Archivo del modelo explore sql_always_having

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

Definición

sql_always_having te permite aplicar una restricción de consulta que los usuarios no pueden cambiar. La restricción se insertará en la cláusula HAVING del SQL subyacente que Looker generará para todas las consultas en la Explorar donde se usa sql_always_having. 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_having al usuario, a menos que mire el SQL subyacente de las consultas que crea.

Ejemplos

Impide que los usuarios miren grupos con menos de 100 pedidos:

# Using Looker references
explore: order {
  sql_always_having: ${count} >= 100 ;;
}

# Using raw SQL
explore: order {
  sql_always_having: COUNT(*) >= 100 ;;
}

Impide que los usuarios miren grupos con menos de USD 1,000 en ingresos:

explore: customer {
  sql_always_having: ${total_revenue} >= 1000 ;;
}

Evite que los usuarios miren grupos con menos de 100 clientes:

explore: order {
  sql_always_having: ${customer.count} >= 100 ;;
  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_having que es parte de una vista unida en lugar de parte de Explorar, es importante usar el parámetro always_join. Considera el siguiente ejemplo:

explore: order {
  sql_always_having: SUM(customer.visits) >= 100 ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

En este caso, sql_always_having hace referencia a una columna de la vista customer unida, en lugar de order Explorar. Dado que sql_always_having 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_having: SUM(customer.visits) >= 100, usaras sql_always_having: ${customer.total_visits} >= 100, 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_having por Explorar

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

Qué debes saber

Existe un parámetro similar para la cláusula SQL WHERE

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

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 del usuario 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.