SqlKata Query Builder VS rick_db

SqlKata is your friend.

Don't know if can be a good pick for the no-ORM requirement but I would take a look at SqlKata which is a nice query builder + execution engine, built on top of Dapper

Not really an ORM. But I have been enjoying SqlKata recently. Works with Dapper but helps reduce SQL strings and makes things like pagination really easy. Also nice for dynamic filters.

That is basically the description of an object mapper, with all the guarantees of an object mapper :). It seems if you actually use the query builder as such, no guarantees exist.

I'm pretty picky regarding query builders and ORM's, to the extent of having written several of them over the years, in different languages (both dynamic and strong typed, unfortunately closed-source). I'm a strong advocate of schema-first design, and usually a query builder will allow you to design your queries explicitly, but having some internal behaviors (such as string concatenation, identifier quoting and automatic in-order separation of parameters and values to be bound) taken care of. As good examples of this, I'd mention golang's goqu (https://github.com/doug-martin/goqu) and - to some extent - C# SqlKata (https://sqlkata.com/). Following my frustrations with Python ORMs, I built my own toy project, sort-of-in-beta, called rickdb (https://github.com/oddbit-project/rick_db).

Less about the exact syntax and more about the tool, for example: https://github.com/sqlkata/querybuilder. I just chose that since it was on top of a search but the idea is the same. Your code generates raw SQL, so it's 100% interchangeable with writing SQL yourself however the builder library deals with the syntax, proper ordering, quoting, full attribute names, etc. Some such libraries even let you define your schema in code to make your SQL generation type safe.

I forgot to add that most of my "custom" implementations are also open-source, to avoid repeating the same boilerplate over and over at different places. Its not "pythonic", and it is at varying degrees of maturity, and honestly, they are mostly for internal use in my projects (documentation is incomplete, interfaces may change, etc), but if you want have a look:

https://github.com/oddbit-project/rick_db - postgresql query builder & object mapper - it is built around the concept of pure data objects (no indirect references do open resources) that can represent application data between layers; It also features a forward-only migration manager;

https://github.com/oddbit-project/rick - plumbing, validation & assorted logic - provides service locators, registries, containers (including dependency injection); validators, forms & request validation (with support for laravel-style validation chains), and a bunch of other stuff;

https://github.com/oddbit-project/pokie - flask-based web meta-framework, focused on REST api design, that brings components from the other two projects into an modular applicational framework;

That is basically the description of an object mapper, with all the guarantees of an object mapper :). It seems if you actually use the query builder as such, no guarantees exist.

I'm pretty picky regarding query builders and ORM's, to the extent of having written several of them over the years, in different languages (both dynamic and strong typed, unfortunately closed-source). I'm a strong advocate of schema-first design, and usually a query builder will allow you to design your queries explicitly, but having some internal behaviors (such as string concatenation, identifier quoting and automatic in-order separation of parameters and values to be bound) taken care of. As good examples of this, I'd mention golang's goqu (https://github.com/doug-martin/goqu) and - to some extent - C# SqlKata (https://sqlkata.com/). Following my frustrations with Python ORMs, I built my own toy project, sort-of-in-beta, called rickdb (https://github.com/oddbit-project/rick_db).