required_joins

Usage

explore: view_name_1 {
  join: view_name_2 { ... }
  join: view_name_3 {
    required_joins: [view_name_2, ...]
  }
}

היררכיה קובץ מודל explore join required_joins

ערך ברירת המחדל ללא מקבל סוגריים מרובעים שמכילים רשימה מופרדת בפסיקים של הצטרפויות לניתוח הזה כללים מיוחדים כדי שאפשר יהיה להפנות לתצוגה ב-required_joins, צריך לצרף אותה לניתוח ב-Explore.

הגדרה

‫required_joins מכריח לכלול joins אחד או יותר ב-SQL שנוצר על ידי Looker, גם אם המשתמש לא בחר שדה מהתצוגה המצורפת הזו. ההתנהגות הזו מופעלת בכל פעם שהמשתמש בוחר שדה מתצוגה קשורה שאתם מציינים. יכול להיות שיהיה צורך בכמה הצטרפויות, באמצעות רשימה מופרדת בפסיקים כמו [join_name_a, join_name_b, ...].

כש-Looker יוצר SQL לשאילתה, הוא מנסה ליצור את ה-SQL הכי נקי שאפשר, וישתמש רק בצירופים שנדרשים לשדות שהמשתמש בוחר. בדוגמה של דיאגרמת התחביר בחלק העליון של הדף הזה:

• אם משתמש בחר רק שדה מ-view_name_2, זו תהיה התצוגה היחידה שמצורפת לניתוח.
• אם משתמש בוחר שדה מ-view_name_3, הפרמטר required_joins של הצירוף הזה גורם לצירוף של view_name_2 לניתוח.

תרחישי השימוש העיקריים ב-required_joins:

• סגנון תחביר ישן עם sql_on
• צריך או רוצה לכתוב SQL גולמי

סגנון תחביר ישן עם sql_on

לא צריך להשתמש ב-required_joins עם sql_on כשמשתמשים בתחביר ${view_name.looker_dimension_name}. עם זאת, יש מודלים ישנים יותר שעדיין משתמשים בתחביר view_name.native_column_name. לדוגמה:

explore: order_items {
  join: order {
    sql_on: order_items.order_id = order.id ;;
  }
  join: customer {
    sql_on: order.customer_id = customer.id ;;
    required_joins: [order]
  }
}

בדוגמה הזו, בכל פעם שמשתמש בוחר שדה מ-customer, צריך לצרף גם את התצוגה order כדי לשמור על יחס הצירוף הנכון. אם שכחתם לדרוש את השאילתות האלה, יכול להיות שהן עדיין יפעלו אם המשתמש יבחר שדות מכל התצוגות הנדרשות. עם זאת, יכול להיות ששאילתות אחרות יחזירו נתונים שגויים בלי להציג הודעה על כך, בגלל האיחוד השגוי.

במקום להשתמש ב-required_joins, כדאי לשנות את המודל כך שישתמש בתחביר ${view_name.looker_dimension_name}.

צריך או רוצה לכתוב SQL גולמי

יש מקרים שבהם אי אפשר או לא רוצים להשתמש בתחביר ${view_name.looker_dimension_name} עם sql_on. בדרך כלל זה קורה כי רוצים להשתמש בערכים הגולמיים במסד הנתונים, ולהימנע מהמרות או משינויים אחרים שמתרחשים באמצעות התחביר ${view_name.looker_dimension_name}. דוגמה לשימוש:

explore: order {
  join: user {
    sql_on: ${order.user_id} = ${user.id} ;;
  }
  join: pre_sign_up_events {
    from: event
    sql_on:
      ${event.user_id} = ${user.id} AND
      event.date BETWEEN user.creation_date AND user.sign_up_date ;;
    required_joins: [user]
    relationship: one_to_many
  }
}

בדוגמה הזו, הצטרפות pre_sign_up_events מסתמכת על תאריכים מ-user. לכן חשוב לוודא ש-user מצטרף באמצעות required_joins.

במקום להשתמש ב-required_joins כדי להימנע מהמרת נתונים בשדות של שעה או תאריך, כדאי להשתמש בסוג date_raw ולהימנע משימוש ב-required_joins.

אתגרים נפוצים

כדי שאפשר יהיה להפנות לתצוגה ב-required_joins, צריך לצרף אותה לניתוח ב-Explore.

כדי להציב תצוגה ב-required_joins, צריך לוודא שהיא מצורפת ל-explore שבו נעשה שימוש ב-required_joins. לדוגמה, הפעולה הבאה לא תעבוד:

explore: order_items {
  join: customer {
    sql_on: order.customer_id = customer.id ;;
    required_joins: [order]
  }
}

החשבון order לא הצטרף ל-order_items, ולכן הוא לא זמין לשימוש ב-required_joins.