Top 23 Go ORM Projects
-
Regarding the interaction with the database, I decided to use an ORM to make the whole process simpler and more intuitive and for that reason I decided to use Gorm, which in my opinion is the most popular ORM in the Go universe and has a great range of features.
-
Ent is my favourite data access layer for Go. It uses code generation to make things type safe, and treats your schema like a graph which IMO makes it way nicer to work with and is one of the reasons I love Ent.
-
OPS
OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.
-
-
Project mention: Is it a good practice to make a wrapper around database? | reddit.com/r/golang | 2022-01-13
Maybe take a look at sqlc (https://sqlc.dev). It nicely wraps/abstracts the database interaction with a database package. Makes it really easy to write "type safe" sql code without the problems you might run into when using object relational mappers.
-
Try sqlboiler. https://github.com/volatiletech/sqlboiler
-
-
SonarQube
Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
-
xo
Command line tool to generate idiomatic Go code for SQL databases supporting PostgreSQL, MySQL, SQLite, Oracle, and Microsoft SQL Server (by xo)
I'm a big fan of the database first code generator approach to talking to an SQL database, so much so that I wrote pggen[1] (not to be confused with pggen[2], as far as I can tell a sqlc fork, which I just recently learned about).
I'm a really big partisan of this approach, but I think I'd like to play the devil's advocate here and lay out some of the weaknesses of both a database first approach in general and sqlc in particular.
All database first approaches struggle with SQL metaprogramming when compared with a query builder library or an ORM. For the most part, this isn't an issue. Just writing SQL and using parameters correctly can get you very far, but there are a few times when you really need it. In particular, faceted search and pagination are both most naturally expressed via runtime metaprogramming of the SQL queries that you want to execute.
Another drawback is poor support from the database for this kind of approach. I only really know how postgres does here, and I'm not sure how well other databases expose their queries. When writing one of these tools you have to resort to tricks like creating temporary views in order infer the argument and return types of a query. This is mostly opaque to the user, but results in weird stuff bubbling up to the API like the tool not being able to infer nullability of arguments and return values well and not being able to support stuff like RETURNING in statements. sqlc is pretty brilliant because it works around this by reimplementing the whole parser and type checker for postgres in go, which is awesome, but also a lot of work to maintain and potentially subtlety wrong.
A minor drawback is that you have to retrain your users to write `x = ANY($1)` instead of `x IN ?`. Most ORMs and query builders seem to lean on their metaprogramming abilities to auto-convert array arguments in the host language into tuples. This is terrible and makes it really annoying when you want to actually pass an array into a query with an ORM/query builder, but it's the convention that everyone is used to.
There are some other issues that most of these tools seem to get wrong, but are not impossible in principle to deal with for a database first code generator. The biggest one is correct handling of migrations. Most of these tools, sqlc included, spit out the straight line "obvious" go code that most people would write to scan some data out of a db. They make a struct, then pass each of the field into Scan by reference to get filled in. This works great until you have a query like `SELECT * FROM foos WHERE field = $1` and then run `ALTER TABLE foos ADD COLUMN new_field text`. Now the deployed server is broken and you need to redeploy really fast as soon as you've run migrations. opendoor/pggen handles this, but I'm not aware of other database first code generators that do (though I could definitely have missed one).
Also the article is missing a few more tools in this space. https://github.com/xo/xo. https://github.com/gnormal/gnorm.
-
upper.io/db
Data access layer for PostgreSQL, CockroachDB, MySQL, SQLite and MongoDB with ORM-like features.
upper.io is a viable alternative to GORM. Just a suggestion.
-
Storm is a simple and powerful toolkit for BoltDB. Basically, Storm provides indexes, a wide range of methods to store and fetch data, an advanced query system, and much more. GitHub: https://github.com/asdine/storm
-
-
xorm
xorm是一个简单而强大的Go语言ORM库，通过它可以使数据库操作非常简便。本库是基于原版xorm的定制增强版本，为xorm提供类似ibatis的配置文件及动态SQL支持，支持AcitveRecord操作 (by xormplus)
-
-
github.com/gobuffalo/pop: CLI (DSL + Explicit SQL), and
-
From the schema, a TypeScript Prisma Client can be generated that can be used in Node.js applications - including Next.js! A Go Prisma Client is also in the works.
-
awesome-go-education
A curated list of awesome articles and resources for learning and practicing Go and its related technologies.
Project mention: Good reference projects to learn from, for beginners | reddit.com/r/golang | 2022-01-19If you want some large projects that are written in go: Kubernetes: https://github.com/kubernetes/kubernetes Moby: https://github.com/moby/moby A general list of awesome go projects: https://github.com/avelino/awesome-go Or a special education page: https://mehdihadeli.github.io/awesome-go-education/
-
-
-
go-queryset
100% type-safe ORM for Go (Golang) with code generation and MySQL, PostgreSQL, Sqlite3, SQL Server support. GORM under the hood.
-
-
-
I'm a big fan of the database first code generator approach to talking to an SQL database, so much so that I wrote pggen[1] (not to be confused with pggen[2], as far as I can tell a sqlc fork, which I just recently learned about).
I'm a really big partisan of this approach, but I think I'd like to play the devil's advocate here and lay out some of the weaknesses of both a database first approach in general and sqlc in particular.
All database first approaches struggle with SQL metaprogramming when compared with a query builder library or an ORM. For the most part, this isn't an issue. Just writing SQL and using parameters correctly can get you very far, but there are a few times when you really need it. In particular, faceted search and pagination are both most naturally expressed via runtime metaprogramming of the SQL queries that you want to execute.
Another drawback is poor support from the database for this kind of approach. I only really know how postgres does here, and I'm not sure how well other databases expose their queries. When writing one of these tools you have to resort to tricks like creating temporary views in order infer the argument and return types of a query. This is mostly opaque to the user, but results in weird stuff bubbling up to the API like the tool not being able to infer nullability of arguments and return values well and not being able to support stuff like RETURNING in statements. sqlc is pretty brilliant because it works around this by reimplementing the whole parser and type checker for postgres in go, which is awesome, but also a lot of work to maintain and potentially subtlety wrong.
A minor drawback is that you have to retrain your users to write `x = ANY($1)` instead of `x IN ?`. Most ORMs and query builders seem to lean on their metaprogramming abilities to auto-convert array arguments in the host language into tuples. This is terrible and makes it really annoying when you want to actually pass an array into a query with an ORM/query builder, but it's the convention that everyone is used to.
There are some other issues that most of these tools seem to get wrong, but are not impossible in principle to deal with for a database first code generator. The biggest one is correct handling of migrations. Most of these tools, sqlc included, spit out the straight line "obvious" go code that most people would write to scan some data out of a db. They make a struct, then pass each of the field into Scan by reference to get filled in. This works great until you have a query like `SELECT * FROM foos WHERE field = $1` and then run `ALTER TABLE foos ADD COLUMN new_field text`. Now the deployed server is broken and you need to redeploy really fast as soon as you've run migrations. opendoor/pggen handles this, but I'm not aware of other database first code generators that do (though I could definitely have missed one).
Also the article is missing a few more tools in this space. https://github.com/xo/xo. https://github.com/gnormal/gnorm.
-
Go ORM related posts
- Using BoltDB as internal database 💾
- Is it a good practice to make a wrapper around database?
- Style/Pattern for Go Database, DTO& Validation Struct
- How not to bleed implementation details (transaction) in the HTTP Handler?
- How to Build REST API using Go Fiber and Gorm ORM
- Database Handling with Golang Gorm (CRUD Handling)
- Sql generator but for SQLite
Index
What are some of the best open-source ORM projects in Go? This list will help you:
| Project | Stars | |
|---|---|---|
| 1 | GORM | 26,523 |
| 2 | ent | 9,668 |
| 3 | Xorm | 6,204 |
| 4 | go-pg | 4,959 |
| 5 | sqlc | 4,658 |
| 6 | SQLBoiler | 4,567 |
| 7 | gorp | 3,546 |
| 8 | xo | 2,989 |
| 9 | upper.io/db | 2,872 |
| 10 | Storm | 1,835 |
| 11 | gormt | 1,660 |
| 12 | xorm | 1,484 |
| 13 | reform | 1,218 |
| 14 | gobuffalo/pop | 1,158 |
| 15 | prisma-client-go | 1,101 |
| 16 | awesome-go-education | 693 |
| 17 | go-sqlbuilder | 692 |
| 18 | godb | 678 |
| 19 | go-queryset | 646 |
| 20 | QBS | 548 |
| 21 | REL | 470 |
| 22 | gnorm | 434 |
| 23 | Zoom | 280 |
Are you hiring? Post a new remote job listing for free.
