always_join

Usage

explore: explore_name {
  always_join: [
    view_name,
    view_name,
    ...
  ]
}

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

ערך ברירת המחדל ללא מקבל סוגריים מרובעים שמכילים רשימה מופרדת בפסיקים של שמות תצוגות כללים מיוחדים כדי להשתמש בתצוגה ב-always_join, צריך להוסיף אותה ל-explore

הגדרה

‫always_join מאלץ לכלול joins אחד או יותר ב-SQL שנוצר על ידי Looker, גם אם המשתמש לא בחר שדה מהתצוגה המצורפת. יכול להיות שיהיה צורך בכמה הצטרפויות, באמצעות רשימה מופרדת בפסיקים כמו [view_name_a, view_name_b, etc].

כש-Looker יוצר SQL לשאילתה, הוא מנסה ליצור את ה-SQL הכי נקי שאפשר, וישתמש רק בצירופים שנדרשים לשדות שהמשתמש בוחר. השימוש ב-always_join מאפשר לכם לכפות הצטרפות ללא קשר למה שקורה.

הפרמטר always_join יכול להיות שימושי כשמבצעים צירוף עם הפרמטר type, והצירוף הוא לא LEFT JOIN. במצב כזה, יכול להיות שהצירוף קריטי להגבלת השורות שמוחזרות בצורה נכונה.

דוגמאות

חשוב לוודא שהשדה member תמיד מצורף לשדה event, גם אם המשתמש לא בוחר שדה מתוך member. ההגדרה הזו מגבילה את התוצאות לאירועים שנוצרו על ידי חברי המועדון בלבד:

explore: event {
  always_join: [member]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
}

חשוב לוודא שהשדות member ו-payment תמיד מצורפים ל-event, גם אם המשתמש לא בוחר שדה מאף אחד מהתצוגות האלה. ההגדרה הזו מגבילה את התוצאות כך שיוצגו רק אירועים שנוצרו על ידי חברי מועדון שכבר שילמו:

explore: event {
  always_join: [member, payment]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
  join: payment {
    sql_on: ${member.payment_id} = ${payment.id} ;;
    type: inner
  }
}

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

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

כדי להציב תצוגה ב-always_join, מוודאים שהיא מצורפת ל-Explore שבו נעשה שימוש ב-always_join. לדוגמה, הפעולה הבאה לא תעבוד:

explore: event {
  always_join: [member]
}

כאן התצוגה member לא צורפה ל-event, ולכן היא לא זמינה לשימוש ב-always_join.

חשוב לדעת

אם אפשר, לא להחיל לוגיקה עסקית בצירופים

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

explore: event {
  always_join: [member]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
}

הדרך המומלצת לבצע את הפעולה הזו ב-Looker היא להשתמש ב-LEFT JOIN כדי לקבל נתוני אירועים ונתוני חברים שמשולבים יחד באופן פשוט:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
  }
}

אחר כך תוכלו ליצור מאפיין שאפשר להגדיר לו את הערכים 'כן' או 'לא', כדי לבדוק רק אירועים שקשורים לחברי המועדון:

dimension: is_member_event {
  type: yesno
  sql: ${member.id} IS NOT NULL ;;
}

הגישה הזו מאפשרת למשתמשים לראות את כל האירועים או רק את האירועים של חברי הקהל. לא כפיתם על המשתמשים להסתכל רק על אירועים של חברים באמצעות ההצטרפות.

כשדוח ניתוח כולל את always_join, ערך ברירת המחדל של full_suggestions משתנה ל-yes

כשמשתנה Explore כולל את הפרמטר always_join, ערך ברירת המחדל של full_suggestions משתנה ל-yes. כתוצאה מכך, שאילתת ההצעות תפעל באמצעות הלוגיקה של התכונה 'ניתוח נתונים', כלומר always_join יוחל כדי לצמצם את ההצעות שיוחזרו, והרשימה תכלול רק את הנתונים שהמשתמש אמור לקבל אליהם גישה.

אם מגדירים את full_suggestions ל-no באופן ידני, השאילתה להצעת סינון לא תופעל.