💾 Archived View for tdem.in › post › gorm.gmi captured on 2023-04-19 at 22:28:24. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-06-03)

-=-=-=-=-=-=-

Back to blog

On using GORM: first experience

2021-09-28 21:27

I rarely complain on others' software, but this time I felt compelled to share my first impression on GORM, since it's quite an example of how you pick software you need.

Since you usually don't care much about the upsides but rather have blockers preventing you from using something at all, let's get right to the negative side.

A first glimpse at the docs reveals you don't `(*DB).Close()` after `gorm.Open()`. A more thorough examination results in finding out this is an expected change the author introduced in v1.20. Maybe the point to have the connection pool closed automatically on application exit even is valid, but expecting a Go dev to have to find that out and with a good chance still write something like:

docs

expected change

defer func() {
    sqlDB, _ := db.DB()
    sqlDB.Close()
}()

still looks weird.

While this on itself doesn't look like much of an issue, this is actually a sign of GORM not following semantic versioning, which is baked into the Go toolchain and is illustrated by its docs on version numbers. This means users of `go get -u` might have a difficult time having to patch their code after supposedly minor dependency updates.

semantic versioning

docs on version numbers

I am still going to use this library, after all, it does what I wanted quite well; but hey, I have a right to complain! Right?..