新しい LookML ランタイムは Looker 22.6 以降で利用できます。「ランタイム」は、LookML コードを解釈する Looker の一部です。新しいランタイムは高速化され、従来のランタイムよりも多くの LookML エラーが確認されます。
Looker では、すべてのお客様に新しいランタイムへの移行を強く推奨しています。新しい LookML ランタイムでは、これまで見落とされていたエラーを検出できるため、新しいランタイムを有効にすると、新しい LookML エラーが表示されることがあります。これらのエラーは、新しいランタイムに起因するものではありません。新たに検出できるようになった既存のエラーです。
また、インスタンスを Looker（Google Cloud コア）に変更する場合は、事前に新しいランタイムに移行する必要があります。
新しいランタイムに切り替える方法
1. [以前の LookML ランタイムを使用する] レガシー機能が使用可能な場合は無効にする
一部の Looker では、以前の LookML ランタイムを使用するレガシー機能が有効になっています。Looker インスタンスを新しいランタイムに移行するには、[以前の LookML ランタイムを使用する] レガシー機能を無効にします。
Looker インスタンスの [レガシー機能] 管理ページで [以前の LookML ランタイムを使用する] レガシー機能が使用できない場合、インスタンスはすでに新しいランタイムを使用しています。
2. LookML プロジェクトが new_lookml_runtime:no を使用して構成されていないことを確認する
Looker インスタンスのグローバルな [以前の LookML ランタイムを使用する] 設定をオーバーライドするには、LookML プロジェクトのマニフェスト ファイルに new_lookml_runtime:no ステートメントを追加します。
LookML プロジェクトのマニフェスト ファイルに new_lookml_runtime パラメータがないこと、またはすべての LookML プロジェクトで new_lookml_runtime が yes に設定されていることを確認します。
新しいランタイムが検出する可能性がある LookML の問題
新しいランタイムに移行すると、LookML に新しいエラーが表示されることがあります。この新しいエラーは、新しいランタイムに起因するものではありません。新たに検出できるようになった既存の問題です。
LookML デベロッパーの設定によっては、LookML の変更の送信を続行する前に、これらのエラーを修正する必要があります。次のセクションでは、新しい LookML ランタイムがプロジェクトで検出する可能性がある問題と、その問題を解決する方法について説明します。
- 一部の永続的な派生テーブルが再ビルドされる可能性がある
- Liquid 式内の HTML リテラルが Unicode に変換される場合がある
sql_distinct_key内の無効な参照は「不明なビュー」になる- 主キーのない異なるタイプの測定によって、異なる SQL が生成される
- ベアフィールド参照で Liquid 内の
_filters[]にアクセスすると、参照先フィールドが選択された列として追加される
一部の永続的な派生テーブルが再ビルドされる可能性がある
永続的な派生テーブル（PDT）キーは、LookML ランタイムによって生成された SQL に基づいています。場合によっては、新しいランタイムで PDT に対して異なる（同等の）SQL が生成され、PDT キーが異なることがあります。PDT キーを変更すると、PDT が再ビルドされます。
Liquid 式内の HTML リテラルが Unicode に変換される場合がある
Liquid 式内の HTML タグは、新しいランタイムによって Unicode 相当に変換される場合があります。たとえば、<strong> タグが <strong> に変換されることがあります。以前のランタイムの HTML タグは、次の例のように、直接比較できます。
html:
{{ value |replace(""), "[" |replace(""), "]" }} ;;
新しいランタイムでは、Unicode に対して比較を行う必要があります。
html:
{{ value |replace("<strong>"), "[" |replace("</strong>"), "]" }} ;;
sql_distinct_key 内の無効な参照は「不明なビュー」になる
新しいランタイムでは、不明なフィールドまたはビューを参照する sql_distinct_key は例外をスローします。次に例を示します。
measure: total_shipping {
type: sum_distinct
sql: ${order_shipping} ;;
sql_distinct_key: ${some_incorrect_field_name} ;;
}
主キーのない「異なる」タイプの measure によって、異なる SQL が生成される
primary-key または sql_distinct_key パラメータを使用しない異なるタイプの measure（average_distinct、count_distinct、median_distinct、percentile_distinct、sum_distinct）により、新しいランタイムで異なる SQL が生成される場合があります。
異なるタイプの measure を作成する場合は、必ず primary-key または sql_distinct_key を指定します。
ベアフィールド参照で Liquid 内の _filters[] にアクセスすると、参照先フィールドが選択された列として追加される
Looker では、「ベアフィールド参照」は中かっこで囲まれていないものです（たとえば、${users.created_date} ではなく users.created_date）。
_filters Liquid 変数と併用すると、以前のランタイムではベアフィールド参照が無視されます。新しいランタイムでは、SQL クエリにフィールドが追加されます。
たとえば、このディメンションでは users.created_date がベア参照です。
dimension: name {
html:
{% if _filters[users.created_date] != NULL %}
{{rendered_value}} (created: {{_filters[users.created_date]}})
{% else %}
{{rendered_value}}
{% endif %}
;;
}
従来のランタイムでは、_filters[users.created_date] は常に無視され、{% if %} が満たされた場合に 2 番目の条件のみが適用されます。新しいランタイムでは、条件を評価できるように、users.created_date が SQL クエリの SELECT 句に追加されます。
Looker クエリに予期しないフィールドが自動的に追加されると、ユーザーの混乱を招く可能性があるため、ベアフィールド参照は使用せず、代わりに ${field_name} 構文を使用することをおすすめします。