遷移至新的 LookML 執行階段

自 Looker 22.6 起，即可使用新的 LookML 執行階段。「執行階段」是 Looker 的一部分，負責解讀 LookML 程式碼。新版執行階段的速度更快，且可檢查的 LookML 錯誤比舊版執行階段更多。

Looker 強烈建議所有客戶遷移至新版執行階段。新版 LookML 執行階段可找出先前遭忽略的錯誤，因此啟用新版執行階段可能會導致新的 LookML 錯誤出現。這些錯誤並非由新版執行階段所致，而是先前就存在，現在才被發現。

此外，如要將執行個體變更為 Looker (Google Cloud Core)，客戶必須先遷移至新的執行階段。

如何切換至新執行階段

1. 關閉「使用舊版 LookML 執行階段」舊版功能 (如有)

部分 Looker 啟用「使用舊版 LookML 執行階段」舊版功能。停用「使用舊版 LookML 執行階段」舊版功能，將 Looker 執行個體遷移至新版執行階段。

如果 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 執行階段可能會在專案中發現的問題，以及如何修正這些問題：

部分永久衍生資料表可能會重建

永久衍生資料表 (PDT) 鍵會以 LookML 執行階段產生的 SQL 為基礎。在某些情況下，新的執行階段可能會為 PDT 生成不同 (但等效) 的 SQL，導致 PDT 鍵不同。變更 PDT 鍵會導致 PDT 重建。

Liquid 運算式中的 HTML 常值可能會轉換為 Unicode

新版執行階段可能會將 Liquid 運算式中的 HTML 標記轉換為對應的 Unicode。舉例來說，<strong> 標記可能會轉換為 &lt;strong&gt;。在舊版執行階段中，HTML 標記可以直接比較，如下例所示：

html:
  {{ value |replace(""), "[" |replace(""), "]" }} ;;

在新執行階段中，比較項目必須改為與 Unicode 進行比較：

html:
  {{ value |replace("&lt;strong&gt;"), "[" |replace("&lt;/strong&gt;"), "]" }} ;;

sql_distinct_key 中的無效參照會導致「不明檢視畫面」

使用新執行階段時，如果 sql_distinct_key 參照不明欄位或檢視區塊，就會擲回例外狀況。例如：

measure: total_shipping {
  type: sum_distinct
  sql: ${order_shipping} ;;
  sql_distinct_key: ${some_incorrect_field_name} ;;
}

沒有主鍵的「Distinct」類型指標會產生不同的 SQL

如果相異類型指標 (average_distinct、count_distinct、median_distinct、percentile_distinct、sum_distinct) 沒有 primary-key 或 sql_distinct_key 參數，則新執行階段可能會產生不同的 SQL。

建立不同類型的指標時，請務必指定 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 %} 曾滿足該條件)。新執行階段會在 SQL 查詢的 SELECT 子句中加入 users.created_date，以便評估條件。

如果系統自動將非預期欄位加入 Looker 查詢，可能會讓使用者感到困惑，因此最佳做法是不要使用裸欄位參照，而是使用 ${field_name} 語法。