sql_always_where

Utilizzo

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

Gerarchia File del modello explore sql_always_where

Valore predefinito Nessuno Accetta Una condizione SQL WHERE che utilizza nomi di dimensioni e/o nomi di colonne SQL Regole speciali Se fai riferimento a un nome di colonna SQL in sql_always_where che fa parte di una vista unita anziché di un'esplorazione, è importante utilizzare il parametro always_join o fare riferimento a un nome di campo.

Definizione

sql_always_where ti consente di applicare una limitazione della query che gli utenti non possono modificare. La limitazione verrà inserita nella clausola WHERE dell'SQL sottostante generato da Looker per tutte le query sull'esplorazione in cui viene utilizzato sql_always_where. Oltre alle query eseguite da utenti umani, la limitazione verrà applicata a dashboard, Look pianificati e informazioni incorporate che si basano su questa esplorazione.

La condizione può essere scritta in SQL puro, utilizzando i nomi effettivi di tabelle e colonne del database. Può anche utilizzare riferimenti di Looker come:

• ${view_name.SQL_TABLE_NAME}, che fa riferimento a una visualizzazione di Looker diversa o a una tabella derivata. Tieni presente che SQL_TABLE_NAME in questo riferimento è una stringa letterale, non devi sostituirla con nient'altro.
• ${view_name.field_name}, che fa riferimento a un campo di Looker. L'utilizzo di questo metodo è preferibile al riferimento diretto alle colonne SQL perché Looker può includere automaticamente tutti i join necessari.

Una condizione sql_always_where non viene visualizzata all'utente, a meno che non esamini l'SQL sottostante di qualsiasi query creata.

Esempi

Impedisci agli utenti di visualizzare gli ordini precedenti al 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' ;;
}

Impedisci agli utenti di visualizzare le informazioni sui clienti di Altostrat Corporation:

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

Impedisci agli utenti di visualizzare gli ordini di Altostrat Corporation:

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

Sfide comuni

Se utilizzi SQL non elaborato, potresti dover utilizzare always_join

Se fai riferimento a un nome di colonna SQL in sql_always_where che fa parte di una vista unita, anziché dell'esplorazione, è importante utilizzare il parametro always_join. Considera questo esempio:

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

In questo caso, sql_always_where fa riferimento a una colonna della visualizzazione customer unita, anziché all'esplorazione order. Poiché sql_always_where verrà applicato a ogni query, è importante che anche customer venga unito a ogni query.

Quando Looker genera SQL per una query, tenta di creare l'SQL più pulito possibile e utilizza solo i join necessari per i campi selezionati da un utente. In questo caso, Looker unirebbe customer solo se un utente selezionasse un campo cliente. Utilizzando always_join, puoi forzare l'unione in qualsiasi caso.

Se, invece di sql_always_where: customer.name <> 'Altostrat Corporation', avessi utilizzato sql_always_where: ${customer.name} <> 'Altostrat Corporation', Looker sarebbe abbastanza intelligente da eseguire il join customer senza richiedere l'utilizzo di always_join. Per questo motivo, ti consigliamo di utilizzare i riferimenti ai campi di Looker anziché i riferimenti SQL non elaborati, se possibile.

Utilizza un solo sql_always_where per esplorazione

Dovresti avere un solo sql_always_where in una definizione explore. Inserisci tutto il comportamento desiderato in un unico sql_always_where utilizzando AND e OR in base alle esigenze.

Cose da sapere

Esiste un parametro simile per la clausola SQL HAVING

Esiste un parametro molto simile a sql_always_where chiamato sql_always_having che funziona allo stesso modo, ma applica le condizioni alla clausola HAVING anziché alla clausola WHERE.

Se vuoi che un utente possa modificare i filtri, ma non rimuoverli, prendi in considerazione always_filter

Se vuoi forzare gli utenti a utilizzare un insieme specifico di filtri, ma dove il valore predefinito può essere modificato, prova a utilizzare always_filter.

Se vuoi filtri specifici per gli utenti che non possono essere modificati, valuta la possibilità di access_filter

Se vuoi che un'esplorazione abbia filtri specifici per ogni utente e che non possano essere modificati in alcun modo, puoi utilizzare access_filter.

Quando un'esplorazione include sql_always_where, il valore predefinito di full_suggestions passa a yes

Quando un'esplorazione include il parametro sql_always_where, il valore predefinito di full_suggestions passa a yes. In questo modo, la query dei suggerimenti viene eseguita utilizzando la logica di Explore, il che significa che sql_always_where verrà applicato per restringere i suggerimenti restituiti, limitando l'elenco dei suggerimenti solo ai dati a cui l'utente deve avere accesso.

Se imposti manualmente full_suggestions su no, la query di suggerimento del filtro non verrà eseguita.