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

151–160 of 300 posts

Re: To ORM or Not to ORM

#151

Post by marcosdumay »

bpyne wrote: post #105
Daishiman wrote: post #93

Earlier quoted context omitted.

Frankly that says more about the people you've worked with than the underlying technology. I work with devs that have over a decade of Django experience. We use the ORM because it's just ridiculously easier to write queries on it and because SQL is impossible to compose without substantial problems. 90% of the code we write is CRUD and API endpoints. There's no reason to write SQL by hand except for the complex aggre…

"and because SQL is impossible to compose without substantial problems." Would you mind providing an example of what you mean?

A few features that I miss on SQL that hinder composition:

- A good module system

- View-like variables

- Scoped singletons (related to the module system)

- First class functions

- First class symbols (that can be used as object names)

- Composable queries (related to the view-like variables and first class symbols)

If I wasn't on vacation I would have a few more fresh on memory. Different ones each day.

Re: To ORM or Not to ORM

#152

Post by lenkite »

btilly wrote: post #133
polygotdomain wrote: post #125

Earlier quoted context omitted.

> It's hard to do that in sql in a maintainable way Views

I have spent enough of my life untangling a mess of views that create performance problems to doubt that views are maintainable. Also, there is usually no good solution for keeping the database in sync with code releases. With the result that database+code change synchronization tends to be a source of deployment complexity. Keeping the logic in one place is better than the alternative. And of the two, the tools to m…

We use liquibase https://www.liquibase.org/ for tracking, managing and applying any schema changes. The liquibase changelogs are part of our project releases.

Re: To ORM or Not to ORM

#153

Post by _ea1k »

nullwasamistake wrote: post #147
_ea1k wrote: post #142

Earlier quoted context omitted.

+1 to everything but the last bit. In my experience, the best compromise is something like Hibernate (or some other ORM) for the mapping and the really basic queries (find by ID, find by some random field, etc). Possibly still hibernate for the really advanced crazy stuff, too, though this is more doubtful. I've had pretty good success in the past with Hibernate Geospatial and full text search, for example. In betwee…

+1 for Hibernate. Everyone starts out hating it. The learning curve is steep and unforgiving. But it can do roughly everything SQL can plus everything you would want from an ORM. For the few that actually read the manual, there's strongly typed Criteria queries that have the full power of HQL. Which is basically DB agnostic SQL with a few really advanced features removed. There's also lazy loaded collections, caching…

LOL, I love the way you describe that... "for the few that actually read the manual". That has basically been my experience as well, and the ones that complain the loudest are the ones that refuse to read and understand what is actually happening.

I've also run into a lot of people that loved it at first and then hated it when it first went into production because they didn't read the manual and didn't pay attention to what kind of queries they were actually generating.

I get the feeling that this is why there is often a lot of angst against it from the operations folks.

Re: To ORM or Not to ORM

#154

Post by cryptonector »

dragonwriter wrote: post #139
cryptonector wrote: post #9

Earlier quoted context omitted.

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.

> Or wrap all queries in VIEWs or functions at the RDBMS. This is like the oldest best practice for RDBMS use, for security, and for decoupling consuming apps from each other and the DBs low level implementation (so that app views and base tables can evolve independently to the extent possible), and for maintainability: all app access to the DB should be through views adapted to the apps needs.

Exactly. And it works very well.

I recommend PostgREST to export a RESTful interface to a single PG schema's VIEWs and functions, and RLS and INSTEAD OF triggers as needed.

Re: To ORM or Not to ORM

#155

Post by delusional »

topspin wrote: post #53
toast0 wrote: post #4

Earlier quoted context omitted.

All the time allegedly saved is also more than compensated for when the ORM makes bad queries that are roughly impossible to fix.

Frequently the easiest path to perform a complex query with an ORM results in N+1 performance disasters. The inevitable retort is something like "but the ORM has better ways to do that." Of course it does; ORM implementers aren't incompetent. The key word is "easiest," meaning the ORM user doesn't have to spend time learning anything beyond simply chaining method calls. In production such work goes haywire when resol…

It's the good old "pit of success" story. When doing the right thing is extra work, you will find countless examples of people doing the wrong thing. The only way to always do the right thing is to make that the easiest possible way.

Re: To ORM or Not to ORM

#156

Post by Rapzid »

robodale wrote: post #114
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 "…

After having written queries to populate whatever platform data structures take the result...to mothership-sized ORMS that keep you as far away from SQL as possible, I have to say a middling ORM like Dapper is optimal for me. It's lightweight when you want it to be, but if you want to do some heavier/generic use...it can take you quite far.

Seems reasonable.

A lot of ORMs are built in layers so you can use the foundational bits or the higher level bits at your discretion. Which is why I don't understand the binary argument. "It depends", but a lot of ORMs span the entire "It depends" spectrum..

Re: To ORM or Not to ORM

#157

Post by slow_donkey »

gmac wrote: post #126
hardwaresofton wrote: post #65

While I learn towards not using an ORM, the productivity gains (at the very least early on in development) are undeniable. What I've always looked for are frameworks that give you an ORM but also make lower level queries very easy, normally via a query builder, allowing you to go back and forth between levels of abstraction. If I had to choose, I prefer libraries that give you the lower level of abstractions first an…

I loved TypeORM initially, but came to the conclusion that it was written by people who really got TypeScript, but didn't really get SQL. For example, we were converting from Sequelize, where we were catching unique constraint violations and responding appropriately, and we got quite confused that in TypeORM those errors never got thrown ... until we discovered that TypeORM decides unilaterally (and almost unbelievab…

Would love to see your current setup - I also have the same issue with TypeORM and am sticking with sequelize.

Re: To ORM or Not to ORM

#158

Post by halis »

I was pretty excited when I originally learned about ORMs. But I quickly found that their usefulness is very limited in the enterprise, where most of my career has been spent.

You will likely find, as I did, that enterprises literally have thousands of databases of all kinds and many crazy data models.

They have tomes of huge SQL procedures that are still to this day running their business processes. Maybe even a nice older gent that is the only one that really understands how any of that shit works?

If this sounds familiar to you, then don't waste too much time on ORMs. In my experience, they're only good for mapping out your POJO or POCO objects and performing simple CRUD operations.

Use them to stand up simple REST routes that do CRUD on your entities. That can be the API that you use to do development and testing, and possibly even use those CRUD routes to do larger business operations.

But in reality, the business "requirement" is going to come down to you, the developer, in the form of some old terrible blob of shit SQL. Two thousand lines. Ten thousand lines.

You're probably not going to bother deciphering all that and re-writing it. The ORM is going to barf all over itself if you even try to use its API to execute that query. Even if you could express all those joins and case statements via the ORM, it is going to pick an execution plan where the query finishes sometime after the next Hanukkah.

At this point, don't bother with the ORM. Drop down to some driver where you can just run raw SQL and run the raw SQL.

Create a REST route that just calls this whack query directly.

This all may sound cynical and it is. But I know what I'm talking about. Do yourself a favor and remember what I said.

Re: To ORM or Not to ORM

#159

Post by keithnz »

In F#, you get type providers like

https://fsprojects.github.io/SQLProvider/

or

https://fsprojects.github.io/FSharp.Data.SqlClient/

What is not obvious if you have never seen this before, is that this dynamically connects your database WHILE you are coding and automatically gives you auto completion, fully understands the types, and will give compile errors if your code doesn't match the database. Feels like Magic (or LinqPad if you have ever used that )

The only downside is you need a DB available for your CI build tools ( which is not too difficult to do ). Some F# people will also opt for a light weight mapper like Dapper.

Post reply on HN