sql_always_where

用途

explore: explore_name {
  sql_always_where: ${created_date} >= '2017-01-01' ;;
}
階層
explore
sql_always_where
デフォルト値
なし

許可
ディメンション名や SQL 列名を使用する SQL WHERE 条件

特別なルール
sql_always_where で参照している SQL 列名が、Explore の一部ではなく結合されたビューの一部である場合は、always_join パラメータを使用するか、フィールド名を参照することが重要です。

定義

sql_always_where を使用すると、ユーザーが変更できないクエリ制限を適用できます。この制限は、sql_always_where が使用されている Explore のすべてのクエリについて、Looker が生成する基盤となる SQL の WHERE 句に挿入されます。ユーザーが実行するクエリ以外にも、ダッシュボード、スケジュール化されたLook、そのExploreに依存する組み込まれた情報などに適用されます。

条件は、データベースの実際のテーブル名と列名を使用して、純粋な SQL で記述できます。また、次のような Looker 参照を使用することもできます。

  • ${view_name.SQL_TABLE_NAME}。別の Looker ビューまたは派生テーブルを参照します。この参照の SQL_TABLE_NAME はリテラル文字列です。置き換える必要はありません。
  • ${view_name.field_name}: Looker フィールドを参照します。この方法を使用すると、Looker が必要な結合を自動的に含めることができるため、SQL 列を直接参照するよりも優れています。

sql_always_where 条件は、ユーザーが作成するクエリの基盤となる SQL を確認しない限り、ユーザーには表示されません。

例

ユーザーが 2012 年 1 月 1 日より前の注文を見ることができないように制限します。

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

Altostrat Corporation の顧客情報をユーザーが閲覧できないようにします。

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

ユーザーが Altostrat Corporation の注文を見ることができないようにします。

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

一般的な課題

生の SQL を使用する場合は、always_join の使用が必要になることがあります。

結合されたビューの一部である SQL 列名を sql_always_where で参照する場合は、Explore ではなく、always_join パラメータを使用することが重要です。次の例を考えてみましょう。

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

この場合、sql_always_where は order Explore ではなく、結合された customer ビューの列を参照しています。sql_always_where はすべてのクエリに適用されるため、customer もすべてのクエリで結合することが重要です。

Looker はクエリの SQL を生成する際、可能な限りクリーンな SQL の作成を試み、ユーザーが選択したフィールドに必要な結合のみを使用します。この場合、ユーザーが顧客フィールドを選択した場合にのみ、Looker は customer を結合します。always_join を使用すると、結合を強制的に実行できます。

sql_always_where: customer.name <> 'Altostrat Corporation' の代わりに sql_always_where: ${customer.name} <> 'Altostrat Corporation' を使用した場合、Looker は always_join を使用しなくても customer 結合を作成します。このため、可能な限り、未加工の SQL 参照ではなく Looker フィールド参照を使用することをおすすめします。

Explore ごとに 1 つの sql_always_where のみを使用する

explore 定義に sql_always_where は 1 つだけ指定する必要があります。必要に応じて AND と OR を使用して、必要な動作をすべて 1 つの sql_always_where にまとめます。

知っておくべきこと

SQL の HAVING 句にも同様のパラメータがあります。

sql_always_where と非常によく似たパラメータとして sql_always_having があります。これは同じように動作しますが、WHERE 句ではなく HAVING 句に条件を適用します。

ユーザーが変更できるが削除できないフィルタが必要な場合は、always_filter を検討してください。

特定のフィルタセットをユーザーに強制的に使用させたいが、デフォルト値は変更できるようにしたい場合は、always_filter を試してください。

変更できないユーザー固有のフィルタが必要な場合は、access_filter を検討してください。

Explore に各ユーザーに固有のフィルタを設定し、変更できないようにする場合は、access_filter を使用します。

Explore に sql_always_where が含まれている場合、full_suggestions のデフォルト値が yes に切り替わる

Explore に sql_always_where パラメータが含まれている場合、full_suggestions のデフォルト値は yes に切り替わります。これにより、候補クエリが Explore ロジックを使用して実行されます。つまり、sql_always_where が適用されて返される候補が絞り込まれ、候補リストがユーザーがアクセスできるデータのみに制限されます。

full_suggestions を no に手動で設定すると、フィルタ候補クエリは実行されません。