sql_sempre_ter

Uso

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

Hierarquia Arquivo de modelo explore sql_always_having

Valor padrão Nenhuma Aceita Uma condição HAVING do SQL que usa nomes de medidas e/ou nomes de colunas do SQL Regras 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 que SQL_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.