go-sql-driver/mysql VS sqlc

Next, we need to install some dependencies. We already know we are using MySQL as our database, thus, we need to install the MySQL driver for Golang.

IDE: use whatever make you productive. I personally use vscode. VCS: git, as golang communities use github heavily as base for many libraries. AFAIK Linter: use staticcheck for linting as it looks like mostly used linting tool in go, supported by many also. In Vscode it will be recommended once you install go plugin. Libraries/Framework: actually the standard libraries already included many things you need, decent enough for your day-to-day development cycles(e.g. `net/http`). But here are things for extra: - Struct fields validator: validator - Http server lib: chi router , httprouter , fasthttp (for non standard http implementations, but fast) - Web Framework: echo , gin , fiber , beego , etc - Http client lib: most already covered by stdlib(net/http), so you rarely need extra lib for this, but if you really need some are: resty - CLI: cobra - Config: godotenv , viper - DB Drivers: sqlx , postgre , sqlite , mysql - nosql: redis , mongodb , elasticsearch - ORM: gorm , entgo , sqlc(codegen) - JS Transpiler: gopherjs - GUI: fyne - grpc: grpc - logging: zerolog - test: testify , gomock , dockertest - and many others you can find here

I understand that database/db is an abstraction. As to the driver, sorry, it completely went out of my head. The guide primarily focuses on https://github.com/go-sql-driver/mysql, which is also what I’m interested in.

Authentication method mismatch is not allowed to occur more than once. It is not a part of MySQL protocol. go-sql-driver also has the same rule.

If you are using https://github.com/go-sql-driver/mysql you need to add parseTime=true to the DSN to be able to use time.Time.

package models import ( "gorm.io/driver/mysql" "gorm.io/gorm" ) var DB *gorm.DB func ConnectDatabase() { // refer https://github.com/go-sql-driver/mysql#dsn-data-source-name for details dsn := "root:@tcp(127.0.0.1:3309)/fiber-pscale?charset=utf8mb4&parseTime=True&loc=Local" database, err := gorm.Open(mysql.Open(dsn), &gorm.Config{}) if err != nil { panic("failed to connect database") } // Migrate the users table database.AutoMigrate(&User{}) DB = database }

I've seen this error on line but there is no resolution to this error even when i run go get github.com/go-sql-driver/mysql

I use github.com/go-sql-driver/mysql package to use MySQL. The references are the official README.md, a sample code, the article Masao wrote (in Japanese), and the MariaDB document.

go-sql-driver/mysql 12.1k Stars, Used by 72.4k

> mysql_real_escape_string is still vulnerable when being used with some exotic character sets

Indeed -- mysql_real_escape_string "mostly" fixes this problem by requiring a connection as one of its args, and since it's usually aware of the connection state, it can check that to see if one of those exotic charsets is in-use. But the problem is that there are multiple ways to change the connection charset, some of which the driver is aware of (e.g. in PHP mysqli set_charset) but some it is not (running textual statements like SET NAMES or SET CHARACTER SET).

But generally an attacker won't ever have the ability to set an arbitrary exotic character set for the connection, unless they already have some other sql injection mechanism, in which case it's a moot point :)

Driver documentation also typically mentions this problem. For example, here's the doc for doing client-side param interpolation in the most popular MySQL driver for Golang: https://github.com/go-sql-driver/mysql#interpolateparams

It also explicitly detects if your initial connection settings attempt to use one of those charsets along with param interpolation, and throws an error if so: https://github.com/go-sql-driver/mysql/blob/21f789cd/dsn.go#...

> Couldn't one just save the extra round-trip with length-prefixed strings by sending the query together with the parameters in a single message?

AFAIK, no, not with the traditional MySQL binary protocol. The newer "X protocol" introduced in MySQL 5.7 does allow this, but it is not widely implemented in drivers.

SQLC is a modern marvel. It's not an ORM or a library; it's a code generator. You write raw SQL queries in .sql files, and sqlc generates fully type-safe, idiomatic Go code that you can call in your application.

I've been using the modernc driver for a few years in https://github.com/bbkane/enventory . It's worked perfectly with no drama. Combined with https://sqlc.dev/, I've been very happy writing (small) database applications in Go.

Speaking of Go, if you want compile-time type checking like what SQLx offers, the Go ecosystem has an option that is arguably even better at it:

https://sqlc.dev/

It has the advantage that it implements the parsing and type checking logic in pure Go, allowing it to import your migrations and infer the schema for type checking. With SQLx you need to have your database engine running at compile time during the proc macro execution with the schema already available. This makes SQLx kind of a non-starter for me, though I understand why nobody wants to do what sqlc does (it involves a lot of duplication that essentially reimplements database features.)

What would you use if ORM is to be avoided?

Perhaps something like https://github.com/sqlc-dev/sqlc ?

Next, let's write sql queries for retrieving our users & their permissions. Here we will use sqlc for type-safe code generation from our sql queries, and pgx as its backend

sqlc (https://sqlc.dev/) is amazing, but I needed to use it in several unsupported languages. So instead of creating a plugin for each of those languages, I created a generic one, which is based on go templates.

I really wanted to like sqlc, but it had some major limitations and minor annoyances last time I tried it a few months ago. You might want to go through its list of issues[1] before adopting it.

Things like no support for dynamic queries[2], one-to-many relationships[3], embedded CTEs[4], composite types[5], etc.

It might work fine if you only have simple needs, but if you ever want to do something slightly sophisticated, you'll have to fallback to the manual approach. It's partly understandable, though. It cannot realistically support every feature of every DBMS, and it's explicitly not an ORM. But I still decided to stick to the manual approach for everything, instead of wondering whether something is or isn't supported by sqlc.

[1]: https://github.com/sqlc-dev/sqlc/issues/

[2]: https://github.com/sqlc-dev/sqlc/issues/3414

[3]: https://github.com/sqlc-dev/sqlc/issues/3394

[4]: https://github.com/sqlc-dev/sqlc/issues/3128

[5]: https://github.com/sqlc-dev/sqlc/issues/2760