To ORM or Not to ORM

Post by thymanl23 » Tue, May 07, 2019, 11:52 PM UTC

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

Post by d0100 » Wed, May 08, 2019, 12:01 AM UTC

bkq wrote: post #35

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…

    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
    }

Post by chaostheory » Wed, May 08, 2019, 12:06 AM UTC

jeltz wrote: post #137

chaostheory wrote: post #40

Earlier quoted context omitted.

Have you ever tried it? Your coworkers are right. It also helps you avoid common mistakes like SQL injection. When the ORM doesn't work for a specific case, they usually have ways where you can override the ORM and use your own SQL calls. Virtually every major, popular ORM does this across different languages (can personally confirm with Ruby, Java, & Python ORMs - confident that JS ones support it too).

That is orthogonal. There are ORMs which make SQL injection easy and there are those which make it hard, just as for SQL connector libraries. This is a matter of interface design.

Post by chaostheory » Wed, May 08, 2019, 12:09 AM UTC

megous wrote: post #61

chaostheory wrote: post #40

Earlier quoted context omitted.

Have you ever tried it? Your coworkers are right. It also helps you avoid common mistakes like SQL injection. When the ORM doesn't work for a specific case, they usually have ways where you can override the ORM and use your own SQL calls. Virtually every major, popular ORM does this across different languages (can personally confirm with Ruby, Java, & Python ORMs - confident that JS ones support it too).

SQL injection is prevented by not using user input as a part of the SQL query. It's orthogonal concern to whether to use ORM or not.

Post by joshlemer » Wed, May 08, 2019, 12:19 AM UTC

spion wrote: post #208

derefr wrote: post #206

Earlier quoted context omitted.

So don't map DB records to objects, then. DB records are records , and their proper typing in your business logic is as records —chunks of plain old data, strongly-typed, that your (OO or otherwise) code can declare DB-side interfaces against. The only responsibilities of the module/class that owns the record type, should be getting things converted into and out of that record type. Plain-old-data DB record types (an…

Would that be a "RRM" (Record-Relational mapper)? If so we're already on board (in a different language). P.S. I bet you would never guess which typed language with great support for records makes it easy (for the most part) to build most type-safe SQL queries on the fly, even with projections, without explicitly defining types for every possible projection variation.