A PR into DBeaver: Manticore driver, QA bug, then merge

DBeaver is an app I open almost every day.

Primary database client during development. One day I thought: I use this a lot, why not look at how it’s built. No big reason. Just curiosity, plus an open issue.

The issue was about Manticore Search — a search engine that uses the MySQL wire protocol, but isn’t MySQL. DBeaver didn’t have a dedicated driver yet. People usually connected through the regular MySQL driver. That’s where things started breaking.

DBeaver — the database client I use almost every day

Not my first OSS PR — just the biggest one

I’d already opened a few open-source PRs before. This one was a different size.

DBeaver has tens of thousands of stars. Reviewers are active maintainers. There’s an external label. There’s QA. There’s a founder leaving comments. It felt more serious — not because my code suddenly got great, but because the process ran longer.

The original issue: #35071. There had been an earlier attempt (#40578) — not mine — that went stale. I picked it up again, narrower this time: a dialect that doesn’t use table aliases, plus a meta-model that fits Manticore.

The PR: #41569. Opened July 20, 2026. Merged September 6. About a month and a half.

AI (Cursor) helped. Short version: co-author on commits, an ai-generated label from maintainers. What I still did myself: read the reviews, decide whether to follow or push back, reply quickly.

The bug looked small. “View data” still broke.

Manticore speaks MySQL protocol, but doesn’t support table aliases in FROM / SELECT.

If you use the MySQL driver, DBeaver uses MySQLDialect — and supportsAliasInSelect() is true. Auto-generated SQL ends up like:

SELECT * FROM myindex t

Manticore rejects it. “View data,” which usually just works, turns into an error.

First fix: a dedicated driver + ManticoreSQLDialect that turns aliases off. I copied patterns from other drivers in the codebase (Derby first; later H2/Firebird when the bundle was split out).

Layered review, then QA that made me pause

Early weeks: reviews from E1izabeth. Fair nits — driver description, Connector/J version, too many comments, wiring the dialect through a MetaModel. I tried to reply fast each round. What stuck from this PR: replying to review quickly is more useful than chasing “perfect on the first commit.”

Then it went to QA.

On August 19, uslss posted screenshots. Existing tables weren’t visible in the Navigator. A table created from the UI vanished after refresh. Column types became null.

From QA: tables exist on the server, Navigator is empty

After save/refresh: column types turn null

That’s the part that stuck with me most.

Not because the bug was hard. Because I hadn’t checked through the DBeaver UI — only via dbeaver core. In my head: “it connects.” On screen: empty Navigator. A bit annoying, but fair.

Cause: JDBC DatabaseMetaData.getTables() / getColumns() don’t work on Manticore. Fix: native SQL — SHOW TABLES and DESCRIBE — plus a type list so columns don’t lose their types after refresh.

Same day I replied “Working on it,” pushed the fix, and sent screenshots back.

After SHOW TABLES / DESCRIBE: Navigator works again

Create table, save, refresh still shows it

Create → save → refresh: table stays, types don’t vanish

Its own bundle, then “Merge and pass to QA”

Manticore first sat under ext.generic. Serge Rider (founder) asked to move it into its own bundle — same pattern as H2 / Firebird: org.jkiss.dbeaver.ext.manticore.

Fair request in Eclipse/OSGi land. A new driver, even if it’s mostly dialect overrides, is cleaner as its own plugin. I moved it, registered it in pom.xml + the feature, checked the CE build still included it, and asked for review again.

September 6: a short comment from serge-rider — “Merge and pass to QA.” PR merged into devel.

September 7: uslss replied with one word: “verified.”

Manticore Search driver icon that came with the PR

What I’m taking with me

Three things:

Use the tool you’re contributing to — ideally through the same UI users see. Core tests still help; QA screenshots are more honest.
Follow patterns already in the repo — Derby, H2, Firebird. Maintainers review faster when the shape looks familiar.
Reply to review quickly — small rounds beat going quiet for a while, then rewriting a lot.

I still open DBeaver every day. Difference now: Manticore Search is in the driver list, and I know why it’s there.