On: To ORM or Not to ORM

[bkq]

Personally I think an active record style ORM for Go like gorm is a poor fit for a language that doesn't come across as inherently OOP. Going through some of the documentation for gorm, it seems to rely heavily on method chaining which for Go seems wrong considering how errors are handled in that language. In my opinion, an ORM should be as idiomatic to the language as possible.

I've used sqlx[1] before, and it feels pretty idiomatic to Go. You tag your structs with their respective database columns, write up a query, and hand it to sqlx to perform the deserialisation of the data. I've also come across squirrel[2] too, though I haven't used it, it does look rather interesting.

[1] - https://github.com/jmoiron/sqlx

[2] - https://github.com/masterminds/squirrel

[gen220 → bkq]

For my 2¢, We use squirrel at work (I haven't touched it myself though). People here seem to like it.

It's not an ORM per se, but it seems to occupy the sweet spot you're describing. It takes away some of the more tedious parts of using SQL, but allows you to still reason about what's happening under the hood without committing tons of documentation to memory.

Suits the language quite well, I think!

[d0100 → bkq]

sqlx + squirrel:

    func dbAllPostsInTag(db *sqlx.DB, tagID int64) ([]post, error) {
        posts := []post{}
        query := squirrel.Select("Post.postID, Post.published, Post.title, Post.content").
            From("Post").
            Join("PostTag using(postID)").
            Where(sq.Eq{"tagID ": tagID})

        qSQL, args, err := query.ToSql()
        if err != nil {
            return nil, errors.Wrap(err, "Error generating dbAllPostsInTag sql")
        }
        err = db.Select(&posts, qSQL, args...)
        if err != nil {
            return nil, errors.Wrap(err, "Error listing dbAllPostsInTag")
        }
        return posts, nil
    }