sql_always_where

Uso

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

Hierarquia Arquivo de modelo explore sql_always_where

Valor padrão Nenhum Aceita Uma condição SQL WHERE usando nomes de dimensões e/ou nomes de colunas SQL Regras especiais Se você estiver referenciando um nome de coluna SQL em sql_always_where que faz parte de uma visualização unida em vez de uma análise detalhada, é importante usar o parâmetro always_join ou referenciar um nome de campo.

Definição

O sql_always_where permite aplicar uma restrição de consulta que os usuários não podem mudar. A restrição será inserida na cláusula WHERE do SQL subjacente gerado pelo Looker para todas as consultas na Análise em que sql_always_where é usado. Além das consultas executadas por usuários humanos, a restrição será aplicada a painéis, Looks programados e informações incorporadas que dependem dessa Análise.

A condição pode ser escrita em SQL puro, usando os nomes reais de tabela e coluna 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. SQL_TABLE_NAME nesta referência é uma string literal. Não é necessário substituir por nada.
• ${view_name.field_name}, que faz referência a um campo do Looker. Usar esse método é melhor do que se referir diretamente às colunas SQL porque o Looker pode incluir automaticamente as junções necessárias.

Uma condição sql_always_where não é exibida para o usuário, a menos que ele analise o SQL das consultas criadas.

Exemplos

Impedir que os usuários vejam pedidos anteriores a 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 os usuários vejam informações de clientes da Altostrat Corporation:

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

Impedir que os usuários vejam pedidos da Altostrat Corporation:

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

Desafios comuns

Se você usa SQL bruto, talvez seja necessário usar always_join

Se você estiver referenciando um nome de coluna SQL em sql_always_where que faz parte de uma visualização unida, em vez da análise detalhada, é importante usar o parâmetro always_join. Por exemplo,

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

Nesse caso, sql_always_where está fazendo referência a uma coluna da visualização customer unida, em vez da análise order. Como sql_always_where será aplicado a todas as consultas, é importante que customer também seja unido em todas elas.

Quando o Looker gera SQL para uma consulta, ele tenta criar o SQL mais limpo possível e usa apenas as junções necessárias para os campos selecionados por um usuário. Nesse caso, o Looker só faria a junção com customer se um usuário selecionasse um campo de cliente. Ao usar always_join, você pode forçar a junção a ocorrer, não importa o que aconteça.

Se, em vez de sql_always_where: customer.name <> 'Altostrat Corporation', você usasse sql_always_where: ${customer.name} <> 'Altostrat Corporation', o Looker seria inteligente o suficiente para fazer a junção customer sem exigir que você usasse 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_where por análise detalhada

Só pode haver um sql_always_where em uma definição de explore. Coloque todo o comportamento desejado em um único sql_always_where usando AND e OR conforme necessário.

Informações importantes

Há um parâmetro semelhante para a cláusula HAVING do SQL.

Há um parâmetro muito semelhante ao sql_always_where chamado sql_always_having, que funciona da mesma forma, mas aplica condições à cláusula HAVING em vez da cláusula WHERE.

Se você quiser filtros que um usuário possa mudar, mas não remover, considere always_filter

Se você quiser forçar os usuários a usar um conjunto específico de filtros, mas em que o valor padrão possa ser alterado, tente always_filter.

Se você quiser filtros específicos do usuário que não podem ser alterados, considere usar access_filter

Se você quiser que uma análise detalhada tenha filtros específicos para cada usuário e que não possam ser alterados de forma alguma, use access_filter.

Quando uma análise detalhada inclui sql_always_where, o valor padrão de full_suggestions muda para yes

Quando uma análise detalhada inclui o parâmetro sql_always_where, o valor padrão de full_suggestions muda para yes. Isso faz com que a consulta de sugestões seja executada usando a lógica da Análise detalhada, o que significa que sql_always_where será aplicado para restringir as sugestões retornadas, limitando a lista apenas aos dados que o usuário deve ter acesso.

Se você definir manualmente full_suggestions como no, a consulta de sugestão de filtro não será executada.