sql_sempre_onde

Uso

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

Hierarquia Arquivo de modelo explore sql_always_where

Valor padrão Nenhuma Aceita Uma condição WHERE do SQL que usa nomes das dimensões e/ou nomes das colunas do SQL Regras especiais Se você referenciar um nome de coluna SQL na sql_always_where 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_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 em todas as consultas no Explorar em que sql_always_where 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_where 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 os pedidos antes de 1o de janeiro 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' ;;
}

Impeça que os usuários vejam as informações dos clientes da Periaptly Corporation:

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

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

explore: order {
  sql_always_where: ${customer.name} <> 'Periaptly Corporation' ;;
  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_where 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_where: customer.name <> 'Periaptly Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Nesse caso, o sql_always_where faz referência a uma coluna da visualização customer mesclada, em vez de order. Como sql_always_where 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_where: customer.name <> 'Periaptly Corporation' você usasse sql_always_where: ${customer.name} <> 'Periaptly Corporation', 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_where por exploração

É necessário ter apenas um sql_always_where em uma definição de explore. Coloque todo o comportamento desejado em uma única sql_always_where usando AND e OR, conforme necessário.

Informações úteis

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

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

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 que os filtros específicos do usuário não possam ser alterados, considere usar o 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.