Uso
sql_Always_have: ${count} >= 100 ;;
}
Hierarquia
sql_always_having |
Valor padrão
NenhumaAceita
Uma condição HAVING do SQL que usa nomes de medidas e/ou nomes de colunas do SQLRegras especiais
Se você referenciar um nome de coluna SQL na sql_always_having que faz parte de uma visualização mesclada, em vez de parte de "Explore", é importante usar o parâmetro always_join ou referenciar um nome de campo.
|
Definição
sql_always_having
permite aplicar uma restrição de consulta que os usuários não podem mudar. A restrição será inserida na cláusula HAVING
do SQL subjacente gerado pelo Looker em todas as consultas no Explorar em que sql_always_having
for usado. Além das consultas feitas por usuários humanos, a restrição se aplica a painéis, aparências programadas e informações incorporadas que dependem desse recurso.
A condição pode ser escrita em SQL puro, usando os nomes reais da coluna e da tabela do banco de dados. Ele também pode usar referências do Looker como:
${view_name.SQL_TABLE_NAME}
, que faz referência a uma visualização diferente do Looker ou a uma tabela derivada. Observe queSQL_TABLE_NAME
nesta referência é uma string literal. Não é necessário substituí-la por nada.${view_name.field_name}
, que faz referência a um campo do Looker. Usar esse método é melhor do que consultar diretamente as colunas do SQL porque o Looker pode incluir automaticamente qualquer mesclagem necessária.
Uma condição sql_always_having
não é exibida para o usuário, a menos que ele consulte o SQL subjacente de qualquer consulta criada por ele.
Examples
Impedir que os usuários vejam grupos com menos de 100 pedidos:
# Using Looker references
explore: order {
sql_always_having: ${count} >= 100 ;;
}
# Using raw SQL
explore: order {
sql_always_having: COUNT(*) >= 100 ;;
}
Impeça que os usuários vejam grupos com menos de US $1.000 em receita:
explore: customer {
sql_always_having: ${total_revenue} >= 1000 ;;
}
Impedir que os usuários vejam grupos com menos de 100 clientes:
explore: order {
sql_always_having: ${customer.count} >= 100 ;;
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Desafios comuns
Se você usar o SQL bruto, talvez seja necessário usar always_join
.
Se você referenciar um nome de coluna SQL na sql_always_having
que faz parte de uma visualização mesclada em vez de "Explore", é importante usar o parâmetro always_join
. Veja este exemplo:
explore: order {
sql_always_having: SUM(customer.visits) >= 100 ;;
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Nesse caso, o sql_always_having
faz referência a uma coluna da visualização customer
mesclada, em vez de order
. Como sql_always_having
será aplicado a todas as consultas, é importante que o customer
também seja mesclado em todas as consultas.
Quando o Looker gera SQL para uma consulta, ele tenta criar o SQL mais limpo possível e usa apenas as mesclagens necessárias para os campos selecionados pelo usuário. Nesse caso, o Looker só mesclaria customer
se um usuário selecionar um campo do cliente. Usando always_join
, é possível forçar a mesclagem a ocorrer de qualquer forma.
Se em vez de sql_always_having: SUM(customer.visits) >= 100
você usasse sql_always_having: ${customer.total_visits} >= 100
, o Looker seria inteligente o suficiente para fazer com que customer
participasse sem que você precisasse usar always_join
. Por isso, recomendamos que você use referências de campo do Looker em vez de referências SQL brutas sempre que possível.
Use apenas um sql_always_having
por exploração
É necessário ter apenas um sql_always_having
em uma definição de explore
. Coloque todo o comportamento desejado em uma única sql_always_having
usando AND
e OR
, conforme necessário.
Informações úteis
Há um parâmetro semelhante para a cláusula SQL WHERE
Há um parâmetro muito semelhante a sql_always_having
, chamado sql_always_where
, que funciona da mesma forma, mas aplica condições à cláusula WHERE
em vez de HAVING
.
Se você quiser filtros que um usuário possa mudar, mas não remover, considere usar always_filter
.
Se você quiser forçar os usuários a usar um conjunto específico de filtros, mas o valor padrão puder ser alterado, use always_filter
.
Se você quiser filtros específicos para os usuários que não possam ser alterados, considere usar access_filter
.
Se você quiser que uma exploração tenha filtros específicos para cada usuário e não possa ser alterado, use access_filter
.