We've been using this in production at [redacted] for four months now - it's drastically cut down on the amount of time I spend writing maintaining sql queries, and improved type safety along the way.
What's more impressive is that (prior to this post) this library has had basically no publicity but people have been finding it anyway and picking it up, because it's such an obvious solution to the problem.
Highly recommend switching to this if you're using Go.
Without having a look at the sources yet: could sqlc generated code take any advantage pgx[1] extra features or is it designed to use strictly database/sql?
Lately, I've been building a system in which I want to expose SQL to third party developers. In order to ensure the queries don't abuse the backend, I wrote a SQL grammar using Antlr4 and produce Go code. There's a bit more to what I'm doing aside from restricting what types of queries a user can write, e.g., no joins, no literals (only bind parameters), and a restriction on number of rows returned (Limited to 50).
This query language also abstracts how data is stored on the backend. So when a user does a CREATE TABLE (...), it doesn't actually create a physical table.
I think every developer should play around with creating their own grammar at some point. It's a powerful skill to have.
I really like the Django way where Python code is considered the ground truth. If your model changes in Python, migrations will automatically be generated to reflect the updated state.
AFAIK only TypeORM and really pricey enterprise database software comes with change management systems like this. Even Rails do not have such conveniences.
As you've probably noticed, sqlc is quite different than the Django model. If you're looking for something similar to the Django ORM but for Go, https://gorm.io/ is probably your best bet.
I am referring to migration management in general, not just ORM mapping. The majority of existing ORMs requires you to manually design up and down migrations which can be rather brittle and error-prone.
This looks wonderful and exactly how I'd like to think about such things. Do you generally end up using your db models as the domain models for your application? Or do you have a separate set of models for that, and if so how do you translate between them?
In practice, I use the database models as the domain models for an application. However, if I need to expose the models to the outside world via a service, I create a separate set of models. I then define a set of mapping functions between the two.
What's more impressive is that (prior to this post) this library has had basically no publicity but people have been finding it anyway and picking it up, because it's such an obvious solution to the problem.
Highly recommend switching to this if you're using Go.
It's been great working on sqlc over the last six months. Happy to answer any questions you have about the project.
Without having a look at the sources yet: could sqlc generated code take any advantage pgx[1] extra features or is it designed to use strictly database/sql?
[1] https://github.com/jackc/pgx
If the effort isn't massive I would be up for helping out with that, as that would enable me to use it in a couple of systems.
This query language also abstracts how data is stored on the backend. So when a user does a CREATE TABLE (...), it doesn't actually create a physical table.
I think every developer should play around with creating their own grammar at some point. It's a powerful skill to have.
AFAIK only TypeORM and really pricey enterprise database software comes with change management systems like this. Even Rails do not have such conveniences.
https://docs.microsoft.com/en-us/ef/ef6/modeling/code-first/...
The open source version Entity Framework Core also.