filter

用途

view: view_name {
  filter: filter_name { ... }
}
階層
filter
デフォルト値
なし

許可
フィルタに名前を付けるための Looker 識別子

特別なルール
フィルタ名は、同じ view 内の他のフィルタ、dimensionmeasure と共有できません。

定義

filter パラメータは、フィルタ限定フィールドとそのフィルタの名前を宣言します。ユーザーは、探索時にフィルタ専用フィールドをフィルタとして追加できますが、結果セットに追加することはできません。これらのフィルタ限定のフィールドは、LookML の高度なトピックであるテンプレート フィルタを使用して有用なものにします。filter を使用して非表示フィールドでフィルタするの例もご覧ください。

フィルタ名は次の条件を満たしている必要があります。

  • 任意のビュー内で一意であること
  • az(大文字なし)、09、または _ の文字で構成されている
  • 先頭には英字を使用してください

ディメンション、フィルタ、パラメータのタイプに関するドキュメント ページで詳しく説明しているように、フィルタ フィールドには多くのタイプがあります。

filter のサブパラメータ

LookML フィールドで使用可能なサブパラメータのリストについては、フィールド パラメータのリファレンス ページをご覧ください。

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
  }
}

filtersql パラメータを使用する

また、filtersql パラメータを使用することもできます。これは、フィルタに値があるたびに 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')

sql パラメータを filter で使用する方法の例については、このページの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 に入力を指定し、フィルタ order_region がディメンション region に値を指定しています。region ディメンションは、派生テーブルの SQL で WHERE 句の値を提供します。また、filter 定義の sql パラメータにより、Looker で生成されたクエリの WHERE 句の値も提供します。

filter を使用して非表示フィールドでフィルタする

filter を使用すると、ユーザーがフィルタできるディメンションを作成しながら、ユーザーがクエリでディメンションを選択できないようにすることができます。

  1. まず、hidden: yes を使用して、問題のディメンションを非表示にします。つまり、ユーザーは Explore フィールド ピッカーからこのディメンションを選択できません。

      dimension: field_to_hide {
        type: string
        hidden: yes
        sql: ${TABLE}.field_to_hide ;;
      }
    
  2. 次に、field_to_hide ディメンションにリンクする filter フィールドを作成します。

    filter: filter_on_field_to_hide {
      type: string
      sql: {% condition filter_on_field_to_hide %} ${field_to_hide} {% endcondition %} ;;
    }
    

filtersql パラメータを使用するで説明したように、filter フィールドの sql パラメータは、クエリの WHERE 句に SQL を直接適用します。この場合、sqlfilter_on_field_to_hide フィルタで指定されたフィルタ条件を取得し、${field_to_hide} ディメンションに適用します。

これにより、ユーザーは filter_on_field_to_hide フィルタを使用して field_to_hide でクエリをフィルタできますが、field_to_hide ディメンションは非表示のままになります。