DynamoDB Query Builder
Susun seluruh permintaan Query atau Scan — tabel, indeks, kondisi kunci, filter, proyeksi, Limit, urutan, pembacaan konsisten, dan penomoran halaman — lalu salin program siap jalan untuk AWS SDK v3, DocumentClient, CLI, boto3, Java, Go, .NET, Rust, Kotlin, PHP, Ruby, atau DynamoDB-Toolbox, atau pernyataan PartiQL-nya.
dynamodb-expression-builder adalah pustaka open source (MIT) di balik alat ini.
Dari pola akses ke request yang bisa dijalankan
Expression jarang menjadi keseluruhan pekerjaan. Query produksi juga menentukan index mana yang dibaca, berapa banyak Item yang dievaluasi per request, ke arah mana sort key berjalan, apakah pembacaan harus strongly consistent, dan apa yang terjadi saat respons kembali membawa LastEvaluatedKey. Parameter tingkat request itu hidup di luar string expression — dan di situlah snippet hasil salin-tempel biasanya keliru.
Builder ini memperlakukan request sebagai satuan kerja. Anda menyusun key condition, filter, dan projection di atas model bertipe dan aman terhadap reserved word yang sama dengan yang dipakai Expression Builder kami, lalu mengatur opsi request di sampingnya. Keluarannya bukan potongan: ia program yang bisa Anda jalankan — import, penyiapan klien, pemanggilan itu sendiri, dan, saat Anda mengaktifkan “Ambil semua halaman”, loop ExclusiveStartKey yang menguras setiap halaman hasil.
Kode yang dihasilkan tetap jujur untuk setiap target. AWS CLI melakukan paginasi sendiri, jadi Limit-nya menjadi --page-size dan eksekusi satu-request mendapat --no-paginate; PartiQL menolak parameter yang milik API ExecuteStatement alih-alih pernyataannya; dan Query menurun menjadi ORDER BY pada sort key Anda bila itu bisa diekspresikan.
Hanya butuh expression-nya saja — condition, filter, atau update expression beserta map placeholder-nya, untuk salah satu dari enam operasi? DynamoDB Expression Builder dibuat persis untuk itu. Masih memutuskan di antara dua operasi baca itu? Query vs Scan menguraikan kapan masing-masing menjadi pilihan yang tepat.
Pertanyaan yang sering diajukan
Apa bedanya dengan DynamoDB Expression Builder?
Keduanya sengaja membagi masalah. Expression Builder berfokus pada sintaks expression — key condition, filter, update dan condition expression beserta map ExpressionAttributeNames/Values-nya — untuk keenam operasi, dan menghasilkan perintah mentahnya saja. Query Builder berfokus pada request Query atau Scan yang lengkap: tabel dan index, key condition, filter, projection, plus parameter tingkat request yang tidak diekspos tool expression (Limit, urutan sortir, ConsistentRead, ExclusiveStartKey), dan menghasilkan program yang bisa dijalankan dengan penyiapan klien serta loop paginasi opsional.
Apa yang sebenarnya dibatasi Limit pada Query atau Scan?
Limit membatasi berapa banyak Item yang dievaluasi DynamoDB per request, bukan berapa banyak Item cocok yang Anda terima. Filter dijalankan setelah pembacaan, jadi Query dengan Limit 25 dan sebuah FilterExpression bisa mengembalikan kurang dari 25 Item — atau tidak sama sekali — sambil tetap mengonsumsi kapasitas baca untuk semua yang dievaluasi, dan paginasi berlanjut dari LastEvaluatedKey. Di AWS CLI, yang melakukan paginasi otomatis, parameter yang sama diatur dengan --page-size.
Bagaimana cara kerja paginasi DynamoDB (LastEvaluatedKey)?
Respons Query atau Scan yang masih punya data lanjutan menyertakan LastEvaluatedKey — kunci utama dari item terakhir yang dibaca. Anda mengirimkannya kembali sebagai ExclusiveStartKey pada permintaan berikutnya dan mengulanginya sampai datang respons tanpa kunci itu. Aktifkan “Ambil semua halaman” dan program SDK v3, boto3, Java, serta .NET yang dihasilkan berisi persis perulangan tersebut; Go, Rust, Kotlin, PHP, Ruby, dan DocumentClient memakai paginator bawaan SDK-nya; AWS CLI menelusuri halaman dengan sendirinya kecuali Anda menambahkan --no-paginate.
Kapan saya bisa memakai pembacaan strongly consistent?
ConsistentRead berfungsi pada tabel dasar dan local secondary index, tetapi tidak pada global secondary index — Query ke GSI dengan ConsistentRead aktif akan ditolak. Pembacaan strongly consistent juga mengonsumsi kapasitas baca dua kali lipat dibanding yang eventually consistent. Ini parameter API, bukan bagian dari teks pernyataan PartiQL — itulah sebabnya tab PartiQL menolaknya dengan jujur.
Apakah yang saya masukkan di sini diunggah ke mana pun?
Tidak. Ini halaman statis: request disusun dan kodenya dihasilkan sepenuhnya di browser Anda, jadi nama tabel, nilai key, dan filter tidak pernah sampai ke server. “Salin tautan” mengemas seluruh request ke dalam URL — membagikan tautan itu adalah satu-satunya cara sesuatu yang Anda ketik keluar dari halaman, dan itu ada di tangan Anda.