I was going to review this but on first glance I don't understand it at all. Feldera adapters are written in Rust and go in the adapters crate. This is something else completely different written in Python and I don't see how it is a Feldera adapter at all.

Hey @blp,

This is not a Feldera adapter, this is a dbt adapter:

https://www.getdbt.com/

dbt is a super popular CLI tool used by Data Engineers/Analysts. The idea of building a dbt adapter is to increase Feldera adoption amongst laymans.

Here are some dbt adapters for other ETL/Database engines, they're all written in Python:

https://github.com/dbt-labs/dbt-adapters

I suppose whoever wrote the Python client for Feldera would be a more suitable reviewer, as this PR is using that client to bridge dbt to feldera.

Hey @blp,

This is not a Feldera adapter, this is a dbt adapter:

https://www.getdbt.com/

OK. I will remove myself from the reviewers list, because I am not the right person to look at this.

@mdrakiburrahman Mihai should definitely look at this, but is traveling so might be slow to reply. In the meantime, tagging in @snkas who understands the python API well.

@lalithsuresh - no rush! I still have a few TODOs to get this PR merge worthy, but I'm curious to get feedback on how I'm bridging the SQL to REST API ~~(currently it's janky RegEx 🙃) - I'm changing to sqlglot - it's a zero-dep Python based SQL Parser (it's awesome, similar to Calcite)

also @abhizer

@gz would you mind allowing CI to run on the latest commit? I was seeing a ruff lint failure in GH Action, hopefully this fixes it

looks like it passed pre-merge queue. if you think it's in good shape I can clone the branch and trigger a run for the merge queue so that it doesnt actually merge it yet. but it may reveal some issues with CI scripts. let me know if you think it's ready to be tried.

@gz let's do it!

I am still on vacation, so I will review more when I get a chance. I apologize for the slow process. I will be out for one more week.

@mihaibudiu no problem at all 🙂 I appreciate you taking the time over the time off.
Will review your latest comments.

I'm not in a rush to merge since there's minimal chances of merge conflicts

https://github.com/feldera/feldera/actions/runs/23948791970

@gz - 1 hour 18 mins, pretty fast post-merge queue!

I am trying to find the dbt integration tests but I think they aren't wired into ci.yml, but looks like the unit tests worked 🚀

@gz yea I removed the dbt integration tests from this PR, I'll get it done in #5966

Currently the integration test only works locally with Docker

Feldera uses rebase-merge, not squash. Every commit in the PR lands individually on main — each with its own message, authored by you. You can verify this by looking at any recently-merged multi-commit PR (e.g. PR #5956 had two commits and both appear separately on main: fc3dd4d and 7d27972).

So yes, the commit messages matter here. 30 commits with checkpoint notes, merge commits, and fixup messages will all become permanent git history.

The fix is straightforward: git rebase -i origin/main to squash, reword, and restructure into a clean sequence. Aim for around 5-10 logical commits that each explain why a change was made. The two merge commits especially need to go (d8afa71e, 044063cc, 2cafef7d, fd88b16d).

References:

• https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
• https://www.seyhan.me/blog/post/lost-art-of-commit-messages

CI passed — good. The commit history still needs the rebase you mentioned in step 3 of your plan. Still seeing checkpoint commits, merge commits, and 'Attempt to lint' scattered through it. Please squash/rebase to a clean logical sequence before I can lift CHANGES_REQUESTED.

If it's not obvious @mythical-fred is our LLM reviewer, he gets fixated on things sometimes :)

Fair point, @gz — CI is green now. @mdrakiburrahman: the only remaining ask is the rebase. Once the history is clean I'll dismiss my REQUEST_CHANGES.

@gz wow could have had me fooled 🤣 I thought it was a git connoisseur engineer

@mythical-fred - calm down robot! I'll do my rebase after finishing the review with Mihai.

Btw we solve all these problems in our repo by enforcing Squash merge. So the developer can push as many commits as they want in their PR branch to get CI green etc, but when it merges to main it shows up as a single clean commit:

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits

(Rebasing can sometimes be stressful unless you're used to it, I've messed up my working branches before but I'm personally not very good at git)

Hey @mihaibudiu,

I think I got your suggestions in the latest batch of commits.

No rush, whenever you're available, please take a look at the latest iteration.

Btw, if you wanted to co-author this branch, please let me know!

I can help get you setup locally (see CONTRIBUTING.md), it's fairly quick to make code changes and fire .scripts/run.sh all to regression test the dbt adapter against a real integration test environment in ~5 minutes.