Nutzung
sql_Always_where: ${created_date} >= '2017-01-01' ;;
}
Hierarchie
sql_always_where |
Standardwert
KeineAkzeptiert
Eine SQL-WHERE -Bedingung mit Dimensionsnamen und/oder SQL-SpaltennamenSonderregeln
Wenn Sie in sql_always_where auf einen SQL-Spaltennamen verweisen, der Teil einer verknüpften Ansicht und nicht Teil der Funktion „Erkunden“ ist, müssen Sie den Parameter always_join verwenden oder auf einen Feldnamen verweisen
|
Definition
Mit sql_always_where
können Sie eine Abfrageeinschränkung anwenden, die Nutzer nicht ändern können. Die Einschränkung wird für alle Abfragen in der explorativen Datenanalyse, in der sql_always_where
verwendet wird, in die WHERE
-Klausel des zugrunde liegenden SQL-Codes eingefügt. Neben den von menschlichen Benutzern ausgeführten Abfragen gilt diese Beschränkung für Dashboards, geplante Looks und eingebettete Informationen, die auf dieses Explore zurückgreifen.
Die Bedingung kann in reinem SQL mit den tatsächlichen Tabellen- und Spaltennamen Ihrer Datenbank geschrieben werden. Es kann auch Looker-Referenzen wie die folgenden verwenden:
${view_name.SQL_TABLE_NAME}
, die auf eine andere Looker-Ansicht oder eine abgeleitete Tabelle verweist. Beachten Sie, dassSQL_TABLE_NAME
in dieser Referenz ein literaler String ist. Sie müssen nicht durch etwas ersetzt werden.${view_name.field_name}
, die auf ein Looker-Feld verweist. Diese Methode ist besser als direkte Verweise auf SQL-Spalten, da Looker automatisch alle erforderlichen Joins hinzufügen kann.
Eine sql_always_where
-Bedingung wird dem Nutzer nur dann angezeigt, wenn er sich den zugrunde liegenden SQL-Code aller von ihm erstellten Abfragen ansieht.
Beispiele
Nutzer daran hindern, Bestellungen vor dem 01.01.2012 anzusehen:
# 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' ;;
}
Verhindern Sie, dass Nutzer die Kundeninformationen für die Periaptly Corporation ansehen:
explore: customer {
sql_always_where: ${name} <> 'Periaptly Corporation' ;;
}
Verhindern Sie, dass Nutzer sich Bestellungen von Periaptly Corporation ansehen:
explore: order {
sql_always_where: ${customer.name} <> 'Periaptly Corporation' ;;
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Häufige Herausforderungen
Wenn Sie Raw-SQL verwenden, müssen Sie möglicherweise always_join
verwenden
Wenn Sie in sql_always_where
auf einen SQL-Spaltennamen verweisen, der Teil einer verbundenen Ansicht ist, ist es wichtig, den Parameter always_join
zu verwenden. Betrachten Sie dieses Beispiel:
explore: order {
sql_always_where: customer.name <> 'Periaptly Corporation' ;;
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
In diesem Fall verweist sql_always_where
auf eine Spalte aus der verknüpften customer
-Ansicht statt auf die Funktion order
„Erkunden“. Da sql_always_where
auf jede Abfrage angewendet wird, muss customer
auch in jeder Abfrage enthalten sein.
Wenn Looker SQL für eine Abfrage generiert, wird versucht, einen möglichst klaren SQL-Code zu erstellen. Dabei werden nur Joins verwendet, die für die vom Nutzer ausgewählten Felder erforderlich sind. In diesem Fall würde Looker nur customer
beitreten, wenn ein Nutzer ein Kundenfeld ausgewählt hat. Mit always_join
können Sie erzwingen, dass die Join-Operation ausgeführt wird, unabhängig davon, was passiert.
Wenn Sie anstelle von sql_always_where: customer.name <> 'Periaptly Corporation'
sql_always_where: ${customer.name} <> 'Periaptly Corporation'
verwendet haben, wäre Looker intelligent genug, um customer
zusammenzuführen, ohne dass Sie always_join
verwenden müssen. Aus diesem Grund empfehlen wir, nach Möglichkeit Looker-Feldverweise anstelle von unbearbeiteten SQL-Referenzen zu verwenden.
Nur ein sql_always_where
pro Erkunden
Sie sollten nur eine sql_always_where
in einer explore
-Definition haben. Verschieben Sie das gewünschte Verhalten mithilfe von AND
und OR
in eine einzelne sql_always_where
.
Wichtige Informationen
Es gibt einen ähnlichen Parameter für die SQL-HAVING-Klausel
Es gibt einen sehr ähnlichen Parameter wie sql_always_where
mit dem Namen sql_always_having
. Er funktioniert auf die gleiche Weise, allerdings werden Bedingungen auf die HAVING
-Klausel und nicht auf die WHERE
-Klausel angewendet.
Wenn Sie Filter möchten, die ein Nutzer ändern, aber nicht entfernen kann, sollten Sie always_filter
verwenden
Wenn Sie möchten, dass Nutzer einen bestimmten Satz Filter verwenden, der Standardwert jedoch geändert werden kann, verwenden Sie stattdessen always_filter
.
Wenn Sie benutzerdefinierte Filter verwenden möchten, die nicht geändert werden können, sollten Sie access_filter
in Betracht ziehen
Wenn Sie möchten, dass ein Filter für jeden Nutzer spezifisch ist und in keiner Weise geändert werden kann, können Sie access_filter
verwenden.