用途
explore: explore_name {
conditionally_filter: {
filters: [field_name: "filter expression", field_name: "filter expression", ...]
unless: [field_name, field_name, ...]
}
}
|
階層
conditionally_filter |
デフォルト値
なし
許可
フィールド名と Looker フィルタ式の 1 つ以上のフィルタ仕様と、unless セクションの 1 つ以上のフィールド名のリスト |
定義
conditionally_filter パラメータを使用すると、ユーザーが定義した 2 番目のリストから少なくとも 1 つのフィルタを適用した場合にオーバーライドできるデフォルトのフィルタセットを定義できます。
このパラメータは、負荷が大きすぎてデータベースで実行できないほど大規模なクエリを、ユーザーが意図せず作成するのを防止するために使用されるのが一般的です。たとえば、ユーザーが明示的に大きな期間をリクエストしていない限り、クエリを前週に制限するように強制できます。
conditionally_filter で適用されたフィルタは、クエリの実行後にユーザーに表示されます。ユーザーは設定したデフォルトの value を変更できますが、unless サブパラメータで指定したフィルタを 1 つ以上適用しない限り、フィルタを完全に削除することはできません。
使用するフィールド名は、dimension または measure の名前にできます。
この Explore の一部ではなく、結合されたビューの一部であるディメンションまたはメジャーを参照するには、view_name.field_name を使用します。
例
次に例を示します。
explore: order {
conditionally_filter: {
filters: [id: "123", customer.id: "678,789"]
unless: [date]
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
この場合、id フィルタは、order という名前の Explore の id フィールドを参照します。customer.id フィルタは、customer というビューの id フィールドを参照します。ユーザーが Explore UI で注文日を設定しない限り、両方のフィルタが適用されます。この例では、複数のフィルタを必須にすることもできることを示しています。
指定するデフォルト値には、これらの種類の式を使用できます。
また、ユーザーが注文日フィルタを適用しない限り、注文 ID フィルタ（デフォルト値は「123」で、変更可能）の使用を強制することもできます。
explore: order {
conditionally_filter: {
filters: [id: "123"]
unless: [date]
}
}
または、注文日フィルタまたは注文時間フィルタを適用しない限り、ユーザーが注文 ID フィルタ（デフォルト値は「123」または「234」で、変更可能）を使用するように強制します。
explore: order {
conditionally_filter: {
filters: [id: "123,234"]
unless: [date, time]
}
}
または、ユーザーが 注文日または顧客日のフィルタを適用しない限り、注文 ID フィルタ（デフォルト値は「123」）と顧客の都市フィルタ（デフォルト値は「シカゴ」）を使用するようにユーザーに強制します。
explore: order {
conditionally_filter: {
filters: [id: "123", customer.city: "Chicago"]
unless: [date, customer.date]
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
一般的な課題
conditionally_filter を使用している場合、すべてのフィルタを削除できない
conditionally_filter を使用する場合、フィルタなしでクエリを実行することはできません。ユーザーは、指定した条件付きフィルタか、unless リストの独自のフィルタを使用する必要があります。
グループ内のディメンション type: time を含む conditionally_filter は、グループの他のディメンションを unless サブパラメータに配置します。
conditionally_filter 内で指定した field がディメンション グループの一部である時間ベースのディメンションの場合、Looker はそのグループの他のすべてのディメンションを、その条件付きフィルタの unless サブパラメータの対象であるかのように扱います。unless サブパラメータを含めない場合でも同様です。
次の 2 つの LookML ブロックは同じように解釈されます。ここで、conditionally_filter は event ディメンション グループの一部である時間ベースのディメンション event_date に適用されます。unless 条件は指定されていませんが、Looker は event グループの他のディメンションを unless サブパラメータで指定されたものとして扱います。
LookML ブロック 1:
explore: logs {
# Make sure there is always a filter on event_date, event_week, event_month or event_year
# Default to the last complete day of data
conditionally_filter: {
filters: [logs.event_date: "1 days ago for 1 day"]
}
view: logs {
# Combine the partition date filters and the time filters into a single field group.
dimension_group: event {
type: time
timeframes: [date,week,month,year]
sql: _PARTITIONTIME ;;
}
}
LookML ブロック 2:
explore: logs {
# Make sure there is always a filter on event_date, event_week, event_month or event_year
# Default to the last complete day of data
conditionally_filter: {
filters: [logs.event_date: "1 days ago for 1 day"]
unless: [event_week, event_month, event_year]
}
view: logs {
# Combine the partition date filters and the time filters into a single field group.
dimension_group: event {
type: time
timeframes: [date,week,month,year]
sql: _PARTITIONTIME ;;
}
}
2 つ目の LookML ブロックのみが event グループの他のディメンションに unless サブパラメータを明示的に適用していますが、Looker は 2 つの LookML ブロックを同じように解釈します。
知っておくべきこと
conditionally_filter をユーザーのサブセットに適用する方法があります
一部のユーザーにのみ条件付きフィルタを適用するには、モデル権限を使用します。conditionally_filter を使用するモデルと使用しないモデルの 2 つを作成する必要があります。その後、ユーザーごとに適切なモデルへのアクセス権を付与できます。
unless なしで conditionally_filter を使用する場合は、代わりに always_filter を使用してください。
ユーザーに特定のフィルター セットを強制的に使用させ、デフォルト値を変更できるようにするには、代わりに always_filter を使用します。
まったく変更できないフィルタが必要な場合は、sql_always_where を検討してください。
Explore に全員に同じフィルタを設定し、ユーザーがフィルタ値を変更できないようにする場合は、sql_always_where を使用します。
変更できないユーザー固有のフィルタが必要な場合は、access_filter を検討してください。
Explore に、ユーザーごとに固有のフィルタを設定し、削除や変更ができないようにする場合は、access_filter を使用します。