Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To ORM or Not to ORM

eli.thegreenplace.net

Post reply on HN
Print view View original

31–40 of 300 posts

Re: To ORM or Not to ORM

#31

Post by mekane8 »

ordinaryperson wrote: post #3

Sample size one 1 but ORM drives me crazy. Why can't we just use SQL? How does it save time when I have to learn the ORM language, which probably has a lot less support and users? The OP here says it "reduces boilerplate" -- rarely have I created an application and thought its biggest problem was too much boilerplate. But everyone at work loves them so I must be wrong somehow.

Reducing boilerplate can be very valuable. Why would you want to spend time writing yet another query when you could be focusing on the parts of the application that deliver value to your customer?

Maintainability is also something to think about. The classes you write for the ORM implicitly document the content model. It can be very hard to decipher the same information from a "show tables" and reading a bunch of SQL SELECT statements, especially if they are all mixed up in the code and broken up with string concatenation and variables. Future maintainers will be able to read the documentation for the ORM which will probably be better than trying to understand a bunch of custom code to deal with complex queries.

For an example of this, notice how in the article the author's "linking table" was nowhere to be found in the ORM section. That got abstracted away! Someone having to analyze the tables directly will be running into those sorts of things all over the place, which is more mental overhead for understanding the system.

Re: To ORM or Not to ORM

#32

Post by airstrike »

ordinaryperson wrote: post #3

Sample size one 1 but ORM drives me crazy. Why can't we just use SQL? How does it save time when I have to learn the ORM language, which probably has a lot less support and users? The OP here says it "reduces boilerplate" -- rarely have I created an application and thought its biggest problem was too much boilerplate. But everyone at work loves them so I must be wrong somehow.

I suppose it depends on your flavor of ORM. My experience using Django has been amazing from day one, and support for more exotic operations has improved by orders of magnitude since I last used it.

I think a good ORM is one that strives to make 80-90% of operations ridiculously easy, leaving edge cases to the developer who can always drop down to a raw query as needed. Django does that fairly well, IMHO, and my limited experience with SQLAlchemy felt pretty underwhelming in comparison

EDIT: Though admittedly I did not have access at the RDBMS level to write VIEWs to match my business needs back when I was using Django. If I did, then perhaps I could have chosen that approach – though I would have to forgo all the useful django-admin stuff that comes out of the box, so there's always a tradeoff...

Re: To ORM or Not to ORM

#33

Post by frosted-flakes »

syntheticcdo wrote: post #7

Somewhere in the middle is best for me. Not quite ORM, not quite raw SQL, but a query builder. In the Node world knexjs.org fits the bill.

I agree with that sentiment. Concatenating strings is miserable and error-prone, especially for highly dynamic queries.

But there's still another step between a full-blown ORM and a query builder, where you still define the models and the relations between them, but fall back to a plain query builder for constructing queries. That way, you're not dealing with plain arrays, etc., but you're still essentially writing SQL. Like Objection.js[0], which is built on Knex.

[0] https://vincit.github.io/objection.js/

Re: To ORM or Not to ORM

#34

Post by vbsteven »

mindcrime wrote: post #23
vbsteven wrote: post #12

Both... I prefer a hybrid approach when it comes to ORM's. In most projects I will use an ORM to avoid boilerplate for simple entity queries (save, findByid, findByX, delete) and converting a database row to a class instance but I avoid mapping complex relations. An ORM like Spring Data with JPA/Hibernate in the Java/Kotlin world works well for this. I write my db schema by hand, create an entity class with the same…

Yep, the Spring Data CrudRepository interface based stuff is an amazing time saver. Just extend an interface, and BOOM, you've got the basic CRUD operations ready to go. And then you just use HQL in annotations for more specialized queries. Other people's mileage may vary, but I've found this to be a tremendous boon.

And there is more:

* you don't have to use HQL, if you pass `nativeQuery=true` in the @Query annotations you can write standard SQL instead of HQL.

* You can add an AccountRepositoryImpl Bean so you have a class in which you can inject dependencies like JdbdTemplate for full JDBC database access.

Re: To ORM or Not to ORM

#35

Post by 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

Re: To ORM or Not to ORM

#36

Post by davidcuddeback »

localhostdotdev wrote: post #25

rails g model Post published_at:datetime title content:text rails g model Comment post:references author published_at:datetime content:text rails g model Tag name rails g model PostTag post:references tag:references class Post from there it's just regular rails: Tag.find_by(name: "something").posts Post.joins(:tags).where(tags: { name: "something" }) Tag.create(name: "something") Post.create(...) Tag.first.posts made…

You forgot to add an index on tags.name and null constraints on the rest of the columns.

> from there it's just regular rails

That's the problem. Examples like this focus on the first few minutes of development. Not the subsequent years of maintenance.

Re: To ORM or Not to ORM

#37

Post by localhostdotdev »

davidcuddeback wrote: post #36
localhostdotdev wrote: post #25

rails g model Post published_at:datetime title content:text rails g model Comment post:references author published_at:datetime content:text rails g model Tag name rails g model PostTag post:references tag:references class Post from there it's just regular rails: Tag.find_by(name: "something").posts Post.joins(:tags).where(tags: { name: "something" }) Tag.create(name: "something") Post.create(...) Tag.first.posts made…

You forgot to add an index on tags.name and null constraints on the rest of the columns. > from there it's just regular rails That's the problem. Examples like this focus on the first few minutes of development. Not the subsequent years of maintenance.

I stayed close to what the author did.

adding an index:

    add_index :tags, :name
adding a null constraint:

    change_column :tags, :name, :string, null: false
    validates :name, presence: true # for proper validations
https://github.com/localhostdotdev/bug/commit/3765237008c36c...

Re: To ORM or Not to ORM

#38

Post by blueplanet200 »

davidcuddeback wrote: post #36
localhostdotdev wrote: post #25

rails g model Post published_at:datetime title content:text rails g model Comment post:references author published_at:datetime content:text rails g model Tag name rails g model PostTag post:references tag:references class Post from there it's just regular rails: Tag.find_by(name: "something").posts Post.joins(:tags).where(tags: { name: "something" }) Tag.create(name: "something") Post.create(...) Tag.first.posts made…

You forgot to add an index on tags.name and null constraints on the rest of the columns. > from there it's just regular rails That's the problem. Examples like this focus on the first few minutes of development. Not the subsequent years of maintenance.

Rails is also fine to maintain down the road. Certainly easier than any data layer most engineers would make by hand.

Re: To ORM or Not to ORM

#40

Post by chaostheory »

ordinaryperson wrote: post #3

Sample size one 1 but ORM drives me crazy. Why can't we just use SQL? How does it save time when I have to learn the ORM language, which probably has a lot less support and users? The OP here says it "reduces boilerplate" -- rarely have I created an application and thought its biggest problem was too much boilerplate. But everyone at work loves them so I must be wrong somehow.

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).
Post reply on HN