使用状況
filter: filter_name { ... }
}
階層
filter |
デフォルト値
なし許可
フィルタに名前を付ける Looker 識別子特別なルール
フィルタ名は、同じ view 内の他のフィルタ dimension 、measure と共有することはできません。 |
定義
filter
パラメータは、フィルタ専用のフィールドと、そのフィルタの名前を宣言します。ユーザーは、フィルタ専用のフィールドをフィルタとして追加することはできますが、結果セットに追加することはできません。このようなフィルタ専用のフィールドは、LookML の高度なトピックであるテンプレート フィルタを使用すると便利です。また、filter
を使用して非表示フィールドでフィルタするもご覧ください。
フィルタ名は次のようにする必要があります。
- 任意のビュー内で一意であること
a
~z
(大文字なし)、0
~9
、または_
で構成します- 先頭には英字を使用してください
さまざまな種類のフィルタ フィールドがあります。詳細については、ディメンション、フィルタ、パラメータの種類に関するドキュメント ページをご覧ください。
例
filter
パラメータの使用例を次に示します。
ユーザー指定のフィルタの作成
ユーザーが order_region
を指定できるようにするフィルタを作成します。
filter: order_region {
type: string
}
テンプレート フィルタを使用した動的派生テーブルの定義
テンプレート化されたフィルタと Liquid パラメータのドキュメントのページにあるように、派生テーブルを定義して、ユーザーが指定した地域における顧客のライフタイム費用を計算します。この例では、前の例で作成した filter
をテンプレート フィルタの一部として使用しています。filter
入力は、Liquid 変数とともに WHERE
句で使用されます。
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id,
SUM(sale_price) AS lifetime_spend
FROM
order
WHERE
{% condition order_region %} order.region {% endcondition %}
GROUP BY 1
;;
}
filter: order_region {
type: string
}
}
filter
で sql
パラメータを使用する
filter
で sql
パラメータを使用することもできます。これは、フィルタに値がある場合は常に SQL WHERE
句に適用されます。これにより、ユーザー フィルタの入力に基づいて動的な WHERE
句を使用できます。
次の例では、データセットに存在するユーザー名のみを許可するフィルタを作成します。
filter: user_enabled {
type: string
suggest_dimension: user_name
sql: EXISTS (SELECT user_id FROM users WHERE {% condition %} user_name {% endcondition %} and state = 'enabled') ;;
}
上の例で、データセットのユーザー名の完全なリストが「Zach」、「Erin」、「Brett」の場合、フィルタは次の WHERE
句になります。
WHERE EXISTS (SELECT user_id FROM users WHERE user_name in ('Zach', 'Erin', 'Brett') and state = 'enabled')
filter
で sql
パラメータを使用する方法の例については、このページのfilter
を使用した隠しフィールドによるフィルタリングをご覧ください。
filter
を使用して、動的な派生テーブルとユーザー定義のフィルタを定義する
動的リージョン値を使用して派生テーブルを定義する前の例では、sql
パラメータとテンプレート フィルタを使用して、派生テーブルと Looker で生成されたメインのクエリの両方に適用される WHERE
句を動的に作成できます。
view: customer_facts {
derived_table: {
sql:
SELECT
customer_id,
SUM(sale_price) AS lifetime_spend
FROM
order
WHERE
{% condition order_region %} order.region {% endcondition %}
GROUP BY 1
;;
}
filter: order_region {
type: string
sql: {% condition order_region %} ${region} {% endcondition %} ;;
}
dimension: region {
type: string
sql: ${TABLE}.region ;;
}
上記の例では、ユーザーがフィルタ order_region
に入力を提供し、次にフィルタの region
ディメンションに値が指定されています。次に、region
ディメンションは派生テーブルの SQL の WHERE
句の値を指定します。また、filter
定義の sql
パラメータにより、Looker で生成されるクエリの WHERE
句の値を提供します。
filter
を使って非表示フィールドでフィルタする
filter
を使用すると、ユーザーがフィルタの対象にできるディメンションを作成でき、同時にユーザーがクエリ内のディメンションを選択することはできなくなります。
- まず、
hidden: yes
を使用して問題のディメンションを非表示にします。つまり、ユーザーはこのディメンションを Explore フィールド選択ツールで選択できません。
dimension: field_to_hide {
type: string
hidden: yes
sql: ${TABLE}.field_to_hide ;;
}
- 次に、
field_to_hide
ディメンションにリンクするfilter
フィールドを作成します。
filter: filter_on_field_to_hide {
type: string
sql: {% condition filter_on_field_to_hide %} ${field_to_hide} {% endcondition %} ;;
}
filter
で sql
パラメータを使用するの例で説明したように、filter
フィールドの sql
パラメータは、クエリの WHERE
句に直接 SQL を適用します。この場合、sql
は filter_on_field_to_hide
フィルタで指定されたフィルタ条件を取得し、それを ${field_to_hide}
ディメンションに適用します。
このようにすることで、ユーザーは filter_on_field_to_hide
フィルタで field_to_hide
でクエリをフィルタリングし、field_to_hide
ディメンションを非表示にできます。