postgresql

Menulis baris settings langsung ke database tidak mengubah respons API yang menyimpan snapshot saat boot. Urutan debug tiga lapis dan aturan restart.

TL;DR: Update settings langsung lewat SQL memang masuk di database, tapi endpoint masih balikin nilai lama soalnya API cuma baca snapshot in-memory yang dibuat pas boot. Nulis SQL itu nggak lewat jalur yang bisa refresh snapshot, makanya datanya kelihatan aman tapi nggak pernah kepakai. Solusinya gampang: habis nulis langsung ke DB, tinggal restart API-nya.

Ketika tipe layanan butuh kategori lintas bidang dan saklar aktif, tabel lookup mengalahkan ENUM.

TL;DR: Awalnya sempat mikir pakai ENUM buat status tipe layanan, tapi ternyata butuh metadata kayak kategori, flag aktif, dan kode unik buat integrasi. Jadinya dibuat tabel lookup, hapus kategori cukup SET NULL biar riwayat data aman. ENUM repot karena nyimpen indeks dan nambah nilai harus ubah skema, validasi tetap dua lapis plus seeding pakai code biar ID stabil.

Data tanggal berbahasa Indonesia membuat kolom event_date kosong terus. Parser locale stdlib bukan jawabannya; tabel bulan eksplisit iya.

TL;DR: Tanggal dari feed dateng dalam bentuk teks kayak Senin, 08 Jun. 2026, tapi mapper cuma coba fromisoformat, jadinya gagal diam-diam dan event_date kosong semua. Ide pake locale Python ketolak soalnya nggak thread-safe plus bug-nya numpuk sejak 2010.

Dua constraint menjaga satu aturan identitas email. Menghapus yang redundan ternyata bukan kosmetik, melainkan menutup celah spesifikasi ganda.

TL;DR: Migrasi ini cuma ngehapus constraint komposit tenant-email dan ganti email jadi unique, intinya satu aturan mending ditulis sekali aja. Soalnya dua spesifikasi buat aturan yang sama itu bahaya—pas aturan berubah, yang lama bisa balik nyala diam-diam. Verifikasinya aman: roundtrip migrasi bersih, autogenerate nggak nemu drift, dan insert duplikat lintas tenant tetap ditolak database.

Tiga kolom enum-like hanya dijaga aplikasi. CHECK constraint memindahkan garansi ke database, dan evolusi nilai jadi operasi murah.

TL;DR: Dulu validasi enum cuma di aplikasi, jadi gampang jebol kalau ada insert manual iseng. Akhirnya ditambah tiga CHECK constraint di database biar nilai ngaco langsung ketolak, nggak pake ENUM native karena ribet kalau mau nambah nilai baru. Untuk tabel kecil validasi langsung full, kalau udah gede pake trik NOT VALID dulu biar nggak ngunci tabel.

Satu angka sukses untuk seluruh batch menyembunyikan kegagalan parsial. Kontrak per-item created/updated/unchanged/rejected membuatnya terlihat.

TL;DR: Endpoint baru /v1/signals:ingest akhirnya nggak pakai satu status buat se-batch, tapi kasih status per item biar kegagalan parsial kelihatan. Tiap item bisa jadi created, updated, unchanged, atau rejected, plus ada pengaman kayak limit ukuran, jumlah item, dan rate limit. Autentikasi pakai Bearer token juga dibenerin, kalau token belum disetting server ngasih 503 bukan 401, dan semua udah dites live.

Observasi yang sama tercatat dua kali hanya karena nama ditulis berbeda. Content hash dari tuple kanonik menutup celah duplikasi itu.

TL;DR: Pipeline sempat ngitung dobel gara-gara nama PT ditulis beda titik sama spasi padahal perusahaannya sama. Makanya dibikin normalize_company buat beresin nama plus content_hash_for yang nge-hash tuple kanonik pakai SHA-256 biar identitasnya konsisten. Terus di database dikunci pakai UniqueConstraint dan ON CONFLICT biar duplikat nggak lolos lagi.

depends_on cuma menunggu container jalan. Healthcheck pg_isready plus service_healthy dan entrypoint yang benar membuat aplikasi tidak menabrak database yang belum siap.

TL;DR: depends_on di Compose cuma mastiin kontainer jalan, bukan beneran nunggu Postgres siap, makanya app sering gagal konek. Solusinya kasih healthcheck pg_isready di db terus depends_on pakai condition service_healthy, plus exec biar uvicorn jadi PID 1 dan shutdown rapi. Pola yang sama kepake di CI GitHub Actions, dan Compose 5.3.0 punya pre_start sebagai alternatif.

Counter bilang 12, tabel bilang 15: filter tanggal ngitung jam yang salah. Perbaikannya hitung dari riwayat transisi, bukan kolom status.

TL;DR: Awalnya angka di dashboard admin nggak sinkron, header bilang 12 tapi tabel malah 15. Ternyata bukan cache error, tapi querynya salah pakai created_at padahal harusnya ngitung dari riwayat changed_at. Akhirnya querynya diganti join ke ticket_history biar hitungannya jujur sesuai kapan status beneran berubah.