To ORM or Not to ORM
eli.thegreenplace.net
To ORM or Not to ORM
1–10 of 300 posts
Re: To ORM or Not to ORM
#2One thing I really miss from the JVM world was something like jOOQ.
I don't want an ORM (like specifically the object relational mapping stuff) for most of my use cases but I do want an abstraction above text for interacting with SQL.
gorm's sql builder is alright but something better would be really nice.
Re: To ORM or Not to ORM
#3Sample 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.
Re: To ORM or Not to ORM
#4Sample 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.
All the time allegedly saved is also more than compensated for when the ORM makes bad queries that are roughly impossible to fix.
Re: To ORM or Not to ORM
#5One thing I really miss from the JVM world was something like jOOQ. I don't want an ORM (like specifically the object relational mapping stuff) for most of my use cases but I do want an abstraction above text for interacting with SQL. gorm's sql builder is alright but something better would be really nice.
Agreed. Really, just an open/transparent SQL builder part and an uncoupled row scanner that can populate structs reflectively is the perfect middleground to work around the impedance mismatch that inevitably occurs using these magic ORMs.
Re: To ORM or Not to ORM
#6Sample 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.
"SQL is too complicated!"
I agree with you. I've experience with a few ORM apps, and, frankly, they always suck. In the beginning everything is perfect because an ORM makes writing trivial DB apps trivial. Then your app grows up and needs more features. Now the ORM only gets in the way, and you can't excise it easily. Now you're in a world of hurt.
Re: To ORM or Not to ORM
#7Somewhere 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.
Re: To ORM or Not to ORM
#8I want to write sql but have my library map between my languages built-in types and my sql types. I feel like something like Dapper is the correct abstraction for communicating with a database.
Re: To ORM or Not to ORM
#9One thing I really miss from the JVM world was something like jOOQ. I don't want an ORM (like specifically the object relational mapping stuff) for most of my use cases but I do want an abstraction above text for interacting with SQL. gorm's sql builder is alright but something better would be really nice.
I don't even want an abstraction for building SQL unless I need to build queries dynamically from some other (presumably simpler) query language.
Put all the SQL in .sql files and make all queries parametrized. Or wrap all queries in VIEWs or functions at the RDBMS. This makes maintenance much easier.
Re: To ORM or Not to ORM
#10Relevant Keynote by DHH https://www.youtube.com/watch?v=zKyv-IGvgGE (tl;dr: ORMs are the best)