PR masuk ke DBeaver: driver Manticore, bug QA, lalu merge

DBeaver itu aplikasi yang hampir tiap hari saya buka.

Primary database client waktu development. Suatu hari kepikiran: sering dipakai, kenapa nggak sekalian lihat isinya dari dalam. Bukan apa-apa. Penasaran saja, ketemu issue yang kebuka.

Issue-nya soal Manticore Search — search engine yang pakai MySQL wire protocol, tapi bukan MySQL. Di DBeaver belum ada driver khusus. Orang biasanya nyambung lewat driver MySQL biasa. Dari situ masalahnya mulai.

---

Bukan PR OSS pertama, tapi yang terbesar

Saya sudah bikin beberapa PR ke open source sebelumnya. Yang ini beda ukuran.

DBeaver puluhan ribu bintang. Reviewer-nya maintainer aktif. Ada label external. Ada QA. Ada founder yang ikut komentar. Rasanya lebih “serius” — bukan karena kode saya tiba-tiba hebat, tapi prosesnya lebih panjang.

Issue aslinya: #35071. Sudah pernah ada attempt sebelumnya (#40578) — bukan saya — lalu stale. Saya ambil lagi, kali ini lebih sempit: dialect yang nggak pakai table alias, plus meta-model yang cocok buat Manticore.

PR-nya: #41569. Dibuka 20 Juli 2026. Merged 6 September. Kurang lebih satu setengah bulan.

AI (Cursor) ikut bantu. Singkat saja: co-author di commit, label ai-generated dari maintainer. Yang tetap saya kerjain sendiri: baca review, mutusin mau ikut atau ngejelasin, balas cepat.

---

Masalahnya kelihatan sepele, tapi bikin “View data” mati

Manticore ngomong protokol MySQL, tapi nggak support table alias di FROM / SELECT.

Kalau user pakai driver MySQL, DBeaver pakai MySQLDialect — dan supportsAliasInSelect()-nya true. Query otomatis jadi kayak:

SELECT * FROM myindex t

Manticore nolak. Fitur “View data” yang biasanya aman langsung error.

Solusi awal: driver sendiri + ManticoreSQLDialect yang matiin alias. Saya tiru pola driver lain di codebase (Derby dulu; nanti H2/Firebird waktu bundle dipisah).

---

Review berlapis, lalu QA yang bikin saya diam sejenak

Minggu-minggu pertama: review dari E1izabeth. Nitpick wajar — deskripsi driver, versi Connector/J, komentar kebanyakan, cara wire dialect lewat MetaModel. Saya coba balas cepat tiap putaran. Dari PR ini yang paling nempel: balas review cepat lebih berguna daripada ngejar “sempurna di commit pertama.”

Lalu masuk QA.

19 Agustus, uslss kirim screenshot. Existing tables nggak kelihatan di Navigator. Table yang dibuat dari UI hilang setelah refresh. Tipe kolom jadi null.

Itu bagian yang paling nempel buat saya.

Bukan karena bug-nya rumit. Karena sebelumnya saya nggak cek lewat UI DBeaver — cuma tes via dbeaver core. Di kepala: “sudah nyambung.” Di layar: Navigator kosong. Agak nyesek, tapi wajar.

Sebabnya: JDBC DatabaseMetaData.getTables() / getColumns() nggak jalan di Manticore. Fix-nya pakai SQL native: SHOW TABLES dan DESCRIBE, plus daftar tipe biar nggak hilang setelah refresh.

Hari yang sama saya balas “Working on it”, push fix, kirim screenshot ulang.

---

Bundle sendiri, lalu “Merge and pass to QA”

Awalnya Manticore masih di ext.generic. Serge Rider (founder) minta dipindah ke bundle sendiri — pola yang sama kayak H2 / Firebird: org.jkiss.dbeaver.ext.manticore.

Request yang masuk akal di dunia Eclipse/OSGi. Driver baru, meski isinya mostly dialect override, lebih rapi kalau punya plugin sendiri. Saya pindahkan, daftarkan di pom.xml + feature, cek CE build masih memuat plugin-nya, request review lagi.

6 September: komentar pendek dari serge-rider — “Merge and pass to QA.” PR merged ke devel.

7 September: uslss balas satu kata: “verified.”

---

Yang saya bawa pulang

Tiga hal:

1. Pakai tool yang kamu kontribusi — idealnya lewat UI yang sama dengan user. Tes core tetap berguna; screenshot QA lebih jujur.
2. Ikuti pola yang sudah ada di repo — Derby, H2, Firebird. Maintainer lebih gampang review kalau bentuknya familiar.
3. Balas review cepat — putaran kecil berkali-kali lebih enak daripada diam lama, lalu rewrite besar.

DBeaver tetap dibuka tiap hari. Bedanya sekarang: di daftar driver ada Manticore Search, dan saya tahu kenapa dia ada di situ.