How does it deal with mapping relationships? For example, a Many-to-Many between Posts and Tags, or a Many-to-One like Posts and Comments?
That's pushing into full-on-ORM. I get the sense that these kind of transforms are not liked by this OP.
How We Went All In on sqlc/pgx for Postgres and Go
41–50 of 160 posts
Re: How We Went All In on sqlc/pgx for Postgres and Go
#42We're using a very similar lib for typescript: https://github.com/adelsz/pgtyped
Would love to hear if any others of comparable or better quality exist for js/ts
Re: How We Went All In on sqlc/pgx for Postgres and Go
#43From the article: > I’ve largely covered sqlc’s objective benefits and features, but more subjectively, it just feels good and fast to work with. Like Go itself, the tool’s working for you instead of against you, and giving you an easy way to get work done without wrestling with the computer all day. I've been meaning to write a blog post about sqlc myself, and when I get to it, I'll probably quote this line. sqlc is…
sqlc definitely uses reflection
But don't let that stop you, it looks like a nice solution and reflection isn't really all that bad anyway :)
Re: How We Went All In on sqlc/pgx for Postgres and Go
#44Earlier quoted context omitted.
They're really not a `must`. What a silly comment - Docker and Kubernetes and substantial parts of Google wouldn't be classed as trivial. For the thousands of devs shipping non-trivial code, keep going!
There's plenty of non-trival code written in C as well. That's not a good argument for the benefit of a programming language. You can work around any limitation with enough work -- this article is a perfect example. It's an ugly solution to a simple problem but it works.
C has few enough restrictions though that you can for example make a struct and then make an array of that struct. In Go this is like rocket science.
Re: How We Went All In on sqlc/pgx for Postgres and Go
#45How does it deal with mapping relationships? For example, a Many-to-Many between Posts and Tags, or a Many-to-One like Posts and Comments?
Relationships are concern of the SQL you provide, not the tool's processing. It is really concerned with only:
1. the inputs used to execute a query
2. the type of output
So whether your query is "SELECT * FROM comments" or "SELECT * FROM comments WHERE comments.postid=$1", the result is still []Comment.
Re: How We Went All In on sqlc/pgx for Postgres and Go
#46> However, without generics, Go’s type system can only offer so much I was reading the whole article waiting to see this line, and the article did not disappoint. This is still the main reason I will stick with Rust or Crystal (depending on the use-case) and avoid Go if I can for the foreseeable future. Generics are just a must these days for non-trivial software projects. It's a shame too because Go has so much prom…
They're really not a `must`. What a silly comment - Docker and Kubernetes and substantial parts of Google wouldn't be classed as trivial. For the thousands of devs shipping non-trivial code, keep going!
> Docker and Kubernetes
Both of these projects have had to go way out of their way to make things work without generics, but they are large enough projects and have enough resources that they can do this. Both are actually really great examples of why Go is a bad choice until generics are added and have first-class support. Even C would be preferable over something where there are no generics.
Re: How We Went All In on sqlc/pgx for Postgres and Go
#47From the article: > I’ve largely covered sqlc’s objective benefits and features, but more subjectively, it just feels good and fast to work with. Like Go itself, the tool’s working for you instead of against you, and giving you an easy way to get work done without wrestling with the computer all day. I've been meaning to write a blog post about sqlc myself, and when I get to it, I'll probably quote this line. sqlc is…
Hopefully they'll get SQLite working on it soon and I'll be all over it.
I'm certainly eager to see official SQLite support as well. In the mean time, the overlap between postgres and SQLite syntax is enough that a lot of my "postgres" definitions in sqlc work just fine in SQLite. The recent addition of "RETURNING" (https://www.sqlite.org/lang_returning.html) to SQLite was a big help since that was a standard part of sql used for postgres with sqlc if you wanted the last insert ID.
Re: How We Went All In on sqlc/pgx for Postgres and Go
#48I've used https://github.com/xo/xo , extended it with some custom functions for templating, extended the templates themselves, and can now generate CRUD for anything in the database, functions for common select queries based on the indices that exist in the database, field filtering and scanning, updates for subsets of fields including some atomic operations, etc. The sky is the limit honestly. It has allowed me to s…
Sounds like a masterful work from you. Planning on open-sourcing your extensions?
Re: How We Went All In on sqlc/pgx for Postgres and Go
#49From the article: > I’ve largely covered sqlc’s objective benefits and features, but more subjectively, it just feels good and fast to work with. Like Go itself, the tool’s working for you instead of against you, and giving you an easy way to get work done without wrestling with the computer all day. I've been meaning to write a blog post about sqlc myself, and when I get to it, I'll probably quote this line. sqlc is…
> Why would someone author an ORM, painstakingly creating Go functions that just map to existing SQL features? The answer to this question lies in the assumption you make in this statement: > the one which every engineer already knows: SQL. Not every engineer knows, or wants to learn, SQL. I've met very competent engineers, SMEs over their particular system, who were flummoxed by SQL. And many more just want to work…
If you are using an ORM and need to write a query that will run on a SQL server you *need SQL knowledge and ORM knowledge*. If you are missing one the two, you probably have just wrote something with big performance penalties. This has been seen over and over in the Rails community.
Re: How We Went All In on sqlc/pgx for Postgres and Go
#50From the article: > I’ve largely covered sqlc’s objective benefits and features, but more subjectively, it just feels good and fast to work with. Like Go itself, the tool’s working for you instead of against you, and giving you an easy way to get work done without wrestling with the computer all day. I've been meaning to write a blog post about sqlc myself, and when I get to it, I'll probably quote this line. sqlc is…
sqlc definitely uses reflection But don't let that stop you, it looks like a nice solution and reflection isn't really all that bad anyway :)
Are you sure? Well, it uses "reflection" in a general sense of introspecting your SQL code, but not in the Go sense of using using type information at runtime via the "reflect" package. sqlc compiles your SQL at build time to statically typed, non-reflect-using functions, as shown here: https://docs.sqlc.dev/en/stable/howto/select.html