sql_always_where

Penggunaan

explore: explore_name {
  sql_always_where: ${created_date} >= '2017-01-01' ;;
}
Hierarki
explore
sql_always_where
Nilai Default
Tidak ada

Menerima
Kondisi SQL WHERE menggunakan nama dimensi dan/atau nama kolom SQL

Aturan Khusus
Jika Anda mereferensikan nama kolom SQL di sql_always_where yang merupakan bagian dari tampilan gabungan, bukan bagian dari Eksplorasi, penting untuk menggunakan parameter always_join -- atau mereferensikan nama kolom

Definisi

sql_always_where memungkinkan Anda menerapkan batasan kueri yang tidak dapat diubah oleh pengguna. Batasan akan dimasukkan ke dalam klausa WHERE dari SQL pokok yang dihasilkan Looker, untuk semua kueri di Jelajah tempat sql_always_where digunakan. Selain kueri yang dijalankan oleh pengguna manusia, pembatasan ini juga akan berlaku untuk dasbor, Look terjadwal, dan informasi tersemat yang mengandalkan Eksplorasi tersebut.

Kondisi dapat ditulis dalam SQL murni, menggunakan nama tabel dan kolom sebenarnya dari database Anda. Anda juga dapat menggunakan referensi Looker seperti:

  • ${view_name.SQL_TABLE_NAME}, yang mereferensikan tampilan Looker lain atau tabel turunan. Perhatikan bahwa SQL_TABLE_NAME dalam referensi ini adalah string literal; Anda tidak perlu menggantinya dengan apa pun.
  • ${view_name.field_name}, yang mereferensikan kolom Looker. Menggunakan metode ini lebih baik daripada merujuk langsung ke kolom SQL karena Looker dapat otomatis menyertakan gabungan yang diperlukan.

Kondisi sql_always_where tidak ditampilkan kepada pengguna, kecuali jika mereka melihat SQL dasar dari kueri apa pun yang mereka buat.

Contoh

Mencegah pengguna melihat pesanan sebelum 01-01-2012:

# 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' ;;
}

Mencegah pengguna melihat informasi pelanggan untuk Altostrat Corporation:

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

Mencegah pengguna melihat pesanan dari Altostrat Corporation:

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

Tantangan umum

Jika menggunakan SQL mentah, Anda mungkin perlu menggunakan always_join

Jika Anda mereferensikan nama kolom SQL di sql_always_where yang merupakan bagian dari tampilan gabungan, bukan Jelajah, Anda harus menggunakan parameter always_join. Perhatikan contoh berikut:

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

Dalam hal ini, sql_always_where merujuk ke kolom dari tampilan customer gabungan, bukan Eksplorasi order. Karena sql_always_where akan diterapkan ke setiap kueri, penting agar customer juga digabungkan di setiap kueri.

Saat membuat SQL untuk kueri, Looker akan mencoba membuat SQL yang paling bersih, dan hanya akan menggunakan gabungan yang diperlukan untuk kolom yang dipilih pengguna. Dalam hal ini, Looker hanya akan menggabungkan customer jika pengguna memilih kolom pelanggan. Dengan menggunakan always_join, Anda dapat memaksa gabungan terjadi apa pun yang terjadi.

Jika, alih-alih sql_always_where: customer.name <> 'Altostrat Corporation', Anda menggunakan sql_always_where: ${customer.name} <> 'Altostrat Corporation', Looker akan cukup pintar untuk membuat gabungan customer tanpa mengharuskan Anda menggunakan always_join. Oleh karena itu, sebaiknya gunakan referensi kolom Looker, bukan referensi SQL mentah jika memungkinkan.

Hanya gunakan satu sql_always_where per Jelajahi

Anda hanya boleh memiliki satu sql_always_where dalam definisi explore. Masukkan semua perilaku yang diinginkan ke dalam satu sql_always_where dengan menggunakan AND dan OR sesuai kebutuhan.

Yang perlu diketahui

Ada parameter serupa untuk klausa SQL HAVING

Ada parameter yang sangat mirip dengan sql_always_where yang disebut sql_always_having yang berfungsi dengan cara yang sama, tetapi menerapkan kondisi ke klausa HAVING, bukan klausa WHERE.

Jika Anda menginginkan filter yang dapat diubah, tetapi tidak dapat dihapus oleh pengguna, pertimbangkan always_filter

Jika Anda ingin memaksa pengguna menggunakan serangkaian filter tertentu, tetapi nilai default dapat diubah, coba gunakan always_filter.

Jika Anda menginginkan filter khusus pengguna yang tidak dapat diubah, pertimbangkan access_filter

Jika Anda ingin Explore memiliki filter yang khusus untuk setiap pengguna, dan tidak dapat diubah dengan cara apa pun, Anda dapat menggunakan access_filter.

Jika Eksplorasi menyertakan sql_always_where, nilai default full_suggestions akan beralih ke yes

Jika Eksplorasi menyertakan parameter sql_always_where, nilai default full_suggestions akan beralih ke yes. Hal ini menyebabkan kueri saran berjalan menggunakan logika Jelajahi, yang berarti sql_always_where akan diterapkan untuk mempersempit saran yang muncul, sehingga membatasi daftar saran hanya pada data yang seharusnya dapat diakses pengguna.

Jika Anda menetapkan full_suggestions ke no secara manual, kueri saran filter tidak akan berjalan.