sql_always_where

Nutzung

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

Akzeptiert
Eine SQL-WHERE-Bedingung mit Dimensionsnamen und/oder SQL-Spaltennamen

Besondere Regeln
Wenn Sie in sql_always_where auf einen SQL-Spaltennamen verweisen, der Teil einer verknüpften Ansicht und nicht Teil des Explores ist, müssen Sie den Parameter always_join verwenden oder stattdessen auf einen Feldnamen verweisen.

Definition

Mit sql_always_where können Sie eine Abfragebeschränkung anwenden, die Nutzer nicht ändern können. Die Einschränkung wird in die WHERE-Klausel des zugrunde liegenden SQL-Codes eingefügt, den Looker für alle Abfragen für den Explore generiert, in denen sql_always_where verwendet wird. 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 können auch Looker-Referenzen wie die folgenden verwendet werden:

  • ${view_name.SQL_TABLE_NAME}, die auf eine andere Looker-Ansicht oder eine abgeleitete Tabelle verweist. In diesem Verweis ist SQL_TABLE_NAME eine literale Zeichenfolge. Sie muss nicht ersetzt werden.
  • ${view_name.field_name}, das auf ein Looker-Feld verweist. Diese Methode ist besser als der direkte Bezug auf SQL-Spalten, da Looker automatisch alle erforderlichen Joins einfügen kann.

Nutzer sehen die Bedingung sql_always_where nur dann, wenn sie sich den entsprechenden SQL-Code ihrer selbst erstellten Abfragen ansehen.

Beispiele

Verhindern, dass Nutzer Aufträge vor dem 01.01.2012 sehen:

# 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' ;;
}

Nutzer daran hindern, Kundeninformationen für Altostrat Corporation einzusehen:

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

Verhindern, dass Nutzer Bestellungen von Altostrat Corporation sehen:

explore: order {
  sql_always_where: ${customer.name} <> 'Altostrat 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 verknüpften Ansicht ist, müssen Sie anstelle des Explores den Parameter always_join verwenden. Betrachten Sie dieses Beispiel:

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

In diesem Fall verweist sql_always_where auf eine Spalte aus der zusammengeführten Ansicht customer anstelle des Explore order. Da sql_always_where auf jede Abfrage angewendet wird, muss customer auch in jede Abfrage eingebunden werden.

Wenn Looker SQL für eine Abfrage generiert, wird versucht, den saubersten möglichen SQL-Code zu erstellen. Es werden nur die Joins verwendet, die für die von einem Nutzer ausgewählten Felder erforderlich sind. In diesem Fall würde Looker nur customer verknüpfen, wenn ein Nutzer ein Kundenfeld auswählt. Mit always_join können Sie den Join erzwingen.

Wenn Sie anstelle von sql_always_where: customer.name <> 'Altostrat Corporation' sql_always_where: ${customer.name} <> 'Altostrat Corporation' verwendet haben, wäre Looker intelligent genug, um den customer-Join auszuführen, ohne dass Sie always_join verwenden müssten. Aus diesem Grund empfehlen wir, nach Möglichkeit Looker-Feldreferenzen anstelle von Roh-SQL-Referenzen zu verwenden.

Nur ein sql_always_where pro Explore verwenden

In einer explore-Definition darf nur ein sql_always_where vorhanden sein. Fassen Sie das gesamte gewünschte Verhalten in einem einzigen sql_always_where zusammen und verwenden Sie dazu bei Bedarf AND und OR.

Wichtige Punkte

Es gibt einen ähnlichen Parameter für die SQL-HAVING-Klausel.

Es gibt einen sehr ähnlichen Parameter wie sql_always_where namens sql_always_having, der auf dieselbe Weise funktioniert, aber Bedingungen auf die HAVING-Klausel anstelle der WHERE-Klausel anwendet.

Wenn Sie Filter verwenden möchten, die Nutzer ändern, aber nicht entfernen können, sollten Sie always_filter in Betracht ziehen.

Wenn Sie Nutzer zwingen möchten, eine bestimmte Gruppe von Filtern zu verwenden, bei denen der Standardwert geändert werden kann, verwenden Sie stattdessen always_filter.

Wenn Sie nutzerspezifische Filter verwenden möchten, die nicht geändert werden können, sollten Sie access_filter in Betracht ziehen.

Wenn Sie möchten, dass ein Explore Filter enthält, die für jeden Nutzer spezifisch sind und in keiner Weise geändert werden können, können Sie access_filter verwenden.

Wenn ein Explore sql_always_where enthält, wird der Standardwert von full_suggestions zu yes geändert.

Wenn ein Explore den Parameter sql_always_where enthält, wird der Standardwert von full_suggestions zu yes geändert. Dadurch wird die Abfrage für Vorschläge mit der Explore-Logik ausgeführt. Das bedeutet, dass sql_always_where angewendet wird, um die zurückgegebenen Vorschläge einzugrenzen. Die Liste der Vorschläge wird also auf die Daten beschränkt, auf die der Nutzer Zugriff haben soll.

Wenn Sie full_suggestions manuell auf no festlegen, wird die Abfrage für Filtervorschläge nicht ausgeführt.