21–28 of 28 posts
This does look like it's a little bit better than a lot of the other options in the Go ecosystem for database access, but this introduction misses something important: what SQL dialects does this support? It appears to be partly a wrapper around Squirrel. Squirrel is not new (and apparently also no longer being updated) but I actually have no idea which and how much of each SQL dialect Squirrel supports. Every time I…
Earlier quoted context omitted.
Type safe sql is a feature of most every production quality db library I’ve used going back 20 years. You don’t need the complexity of an orm to get that. As for trivial boilerplate, I tend to find that trivial boilerplate no more troubling than any of the other compromises orms require, whether that’s polluting my data model with sql concerns or making me conform to db practices that aren’t correct for my needs. And…
I still find myself having the experience of having to unit test trivialities with direct SQL coding, lest I miss a typo, which is a (very basic) thing any ORM or query wrapper will tend to save me from.
Earlier quoted context omitted.
It's easy to drop down to pure SQL in every ORM I've ever used. Meanwhile, a good ORM gives you type safe queries, and saves from having to write boilerplate for trivial CRUD. I honestly would like to know which ORMs most critics have experience with. If it's something terrible like Hibernate, then no wonder. For reference, the ORM I've used the most is Entity Framework (the new one, rewritten for NET Core), and it's…
Modern ORMs like Drizzle and Prisma can probably generate more safe and efficient SQL queries than you could write by hand in a fourth of the time and effort
Just generating sql from native code is not an orm.
This does look like it's a little bit better than a lot of the other options in the Go ecosystem for database access, but this introduction misses something important: what SQL dialects does this support? It appears to be partly a wrapper around Squirrel. Squirrel is not new (and apparently also no longer being updated) but I actually have no idea which and how much of each SQL dialect Squirrel supports. Every time I…
In general, sqlc is very nice to use. It works well out of the box with a standard config. You can also override a lot of things.
One of the nice extras about sqlc is that it doesn't feel like a real dependency.
You don't actually include sqlc anywhere. You just use a config and the cli to generate Go code that relies on the std library. The generated code is very straight forward std Go code that you could write by hand.
A couple of reasons to use Go in a project would be great support for IO, stability, great tooling, low operational complexity and minimal dependencies. sqlc fits nicely in there.
Does this support loading nested models? Lack of this has been a huge pain point with other DB tooling for Go.
[flagged]
Does this support loading nested models? Lack of this has been a huge pain point with other DB tooling for Go.