Qb: Database toolkit for Go (opens in new tab)

I find by far the most useful aspect of ORMs is the query builder, when done well. Much of the time I'm telling my ORM to output in core data types for speed anyway. Having a query builder that allows me to create my own methods for encapsulating common query actions is too useful to give up though.

For example: my @movies = Schema->Movie->recent->starring("brad pitt")->all;, where recent is a method to restrict movies by age, and starring is a method to join on the actors table and restrict to a specific actor.

We released a tool for generating Go types/funcs for databases/queries that might help you with this:

https://github.com/knq/xo

(FWIW I completely agree the added mental overhead for ORMs are not necessary)

The composability of queries that an ORM like ActiveRecord seems like too much of a good thing to give up. Getting the same functionality by cutting and pasting bits of SQL together is much more fragile and far less flexible. Soon enough you find yourself abstracting the various parts of the query (select columns, where clauses etc) and you're on the way to building your own ORM already.

I've abandoned ORMs everywhere. SQL is easy and abstraction layers tend to make easy things slightly easier but harder things much harder.

In the early days, qb has only the builder api. However, I also wanted to have a table builder from structs. Currently, the builder has completely separate implementation from session. The session is the structural composition of builder, engine, metadata, etc. You can see more examples in https://qb.readme.io/docs/the-builder

Feedbacks & Contributions are welcome about the builder.

Did you look at the above work (qb) or have any comments specific to it?

Not liking gorm or orm in general is a common enough attitude, but it feels like an unfair dismissal to not be specific about the posted library and instead criticize it based on your experience with another.

I also might have a misread here, but I doubt people are adopting query builders because they find sql hard, but rather due to combinatorial explosion in manual sql building in some application types.

I agree; it's a little tedious to have to write the boilerplate required, but in the end it works fine. I know exactly what queries my code is running rather than potentially being surprised by what a package/framework may be doing.

The biggest irritation I have is dealing with null values, but the built-in null types in the SQL package are adequate, and there are packages that make them play nice with JSON as well. JSON and array types in Postgres can also be a little cumbersome, but the database packages I've tried don't seem to properly handle them anyway.

I generally have the same feeling, though https://github.com/go-gorp/gorp has worked very well for most of the database-heavy Go projects I've worked on over the last few years. It is just enough abstraction to be convenient and consistent and rarely gets in the way.

it's like an orm but you can also build queries using builder api. It's like sqlalchemy.

The struct tags are grouped like type, constraints, etc. The groups of struct tags is more Gorm currently can't auto migrate keys with foreign keys. There is an issue I've commented but the issue is open for a long time.

There are also some missing features qb doesn't have and gorm has. For instance, you can define relationships in gorm while in qb, you can only define foreign keys using `qb:"constraints:ref(col, table)"`.

Moreover, I am not entirely sure but I don't think enforcing types is possible in gorm. In qb, consider this struct;

type User struct { id string `qb:"type:uuid; constraints:primary_key"` }

qb understands this as a uuid type although it has string definitions. These are the main reasons why I created qb.

The relationship feature is not clear in my mind. I'd like to have feedback on relationships.