sql_always_where

Usage

explore: explore_name {
  sql_always_where: ${created_date} >= '2017-01-01' ;;
}

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

ערך ברירת המחדל ללא מקבל תנאי SQL WHERE שמשתמש בשמות של מאפיינים ו/או בשמות של עמודות SQL כללים מיוחדים אם אתם מפנים לשם של עמודת SQL ב-sql_always_where שהיא חלק מתצוגה שצורפה ולא חלק מהניתוח, חשוב להשתמש בפרמטר always_join או להפנות לשם של שדה במקום זאת

הגדרה

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

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

• ‫${view_name.SQL_TABLE_NAME}, שמפנה לתצוגה אחרת ב-Looker או לטבלה נגזרת. הערה: SQL_TABLE_NAME בהפניה הזו היא מחרוזת מילולית, ולא צריך להחליף אותה בשום דבר.
• ${view_name.field_name}, שמפנה לשדה Looker. השימוש בשיטה הזו עדיף על הפניה ישירות לעמודות SQL, כי Looker יכול לכלול באופן אוטומטי את כל שאילתות האיחוד (join) הנדרשות.

sql_always_where תנאי לא מוצג למשתמש, אלא אם הוא בודק את ה-SQL הבסיסי של שאילתות שהוא יוצר.

דוגמאות

כדי למנוע ממשתמשים לעיין בהזמנות לפני התאריך 2012-01-01:

# Using Looker references
explore: order {
  sql_always_where: ${created_date} >= '2012-01-01' ;;
}

# Using raw SQL
explore: order {
  sql_always_where: DATE(created_time) >= '2012-01-01' ;;
}

למנוע ממשתמשים להסתכל על נתוני לקוח עבור חברת Altostrat:

explore: customer {
  sql_always_where: ${name} <> 'Altostrat Corporation' ;;
}

המשתמשים לא יכולים לראות הזמנות מ-Altostrat Corporation:

explore: order {
  sql_always_where: ${customer.name} <> 'Altostrat Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

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

אם אתם משתמשים ב-SQL גולמי, יכול להיות שתצטרכו להשתמש ב-always_join

אם אתם מפנים לשם של עמודת SQL ב-sql_always_where שהיא חלק מתצוגה עם הצטרפות, במקום ב'ניתוח נתונים', חשוב להשתמש בפרמטר always_join. דוגמה:

explore: order {
  sql_always_where: customer.name <> 'Altostrat Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

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

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

אם במקום sql_always_where: customer.name <> 'Altostrat Corporation' השתמשתם ב-sql_always_where: ${customer.name} <> 'Altostrat Corporation', מערכת Looker תהיה חכמה מספיק כדי לבצע את הצירוף customer בלי שתצטרכו להשתמש ב-always_join. לכן, מומלץ להשתמש בהפניות לשדות של Looker במקום בהפניות ל-SQL גולמי, כשאפשר.

אפשר להשתמש רק ב-sql_always_where אחד בכל ניתוח

צריך להגדיר רק sql_always_where אחד בהגדרה של explore. כדי להגדיר את כל ההתנהגויות הרצויות ב-sql_always_where אחד, משתמשים ב-AND וב-OR לפי הצורך.

חשוב לדעת

יש פרמטר דומה לסעיף HAVING של SQL

קיים פרמטר דומה מאוד ל-sql_always_where שנקרא sql_always_having. הוא פועל באותו אופן, אבל הוא מחיל תנאים על פסקה HAVING במקום על פסקה WHERE.

אם רוצים להגדיר מסננים שהמשתמש יכול לשנות אבל לא להסיר, כדאי לשקול always_filter

אם אתם רוצים לחייב את המשתמשים להשתמש בקבוצה מסוימת של מסננים, אבל לאפשר להם לשנות את ערך ברירת המחדל, כדאי לנסות את האפשרות always_filter.

אם אתם רוצים מסננים ספציפיים למשתמשים שלא ניתן לשנות, כדאי לשקול access_filter

אם רוצים שבדוח Explore יהיו מסננים שספציפיים לכל משתמש, ושאי אפשר לשנות אותם בשום צורה, אפשר להשתמש בaccess_filter.

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

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

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