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

61–70 of 300 posts

Re: To ORM or Not to ORM

#61

Post by megous »

chaostheory wrote: post #40
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).

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.

Re: To ORM or Not to ORM

#62

Post by default-kramer »

rspeele wrote: post #49

I put a ton of work into an ORM that statically typed SQL a couple years ago. I always thought this would be a cool way to go. https://github.com/rspeele/Rezoom.SQL/ But I never got to use it at work, and thus lost interest. The biggest thing missing with it was that you lost type safety if you had to dynamically build a query. These days its main problem is lack of compatibility with .NET Core, which somebody else w…

I really like Rezoom.SQL even though I haven't done a deep dive yet. But that Navigation Properties syntax is enlightening... I just realized that my idealized query language (WIP) needs something similar.

Re: To ORM or Not to ORM

#63

Post by pbreit »

henning wrote: post #20

I wish people did not think the choice was solely between "write raw SQL with raw strings" and "try to pretend the database is object-oriented when it is not." The third approach is to safely wrap the database and its columns with code in a way that is composable. In Python, SQLAlchemy has an ORM, but it is optional, and you can just work with tables and columns if you want.

Would something like Python "records" ever get traction? Just write SQL.

https://github.com/kennethreitz/records

Re: To ORM or Not to ORM

#64

Post by dpcx »

megous wrote: post #59
y4mi wrote: post #15

Earlier quoted context omitted.

I love orms. They make a simple crud operation so easy, you don't even have to think about them. Every remotely competent developer will however tell you that there are always cases where the orm is a bad fit. And that's exactly why basically all orms let you write your own queries. There is really no reason not to use an orm. Just don't ever frown on people doing anything more advanced than a middle join without it.

You don't need ORM for simple CRUD operations. All you need is a function you can pass a table name and a map of column names/values you want to insert/update.

Until you want to be able to sort and filter and do all of the other things that most CRUD applications do.

Once you're there, if you're doing SQL directly, now you're manipulating strings in your code, instead of being able to build some kind of object that then generates a query for you.

Re: To ORM or Not to ORM

#65

Post by hardwaresofton »

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 and then build upon those to offer an OOP-based ORM approach (which is what I believe most people think of when they say "ORM").

It's a spectrum to me:

raw (parametrized) queries ------ query builder + serialiation/deseralization ---------------- OOP-based ORM

One of the best libraries I've ever seen get this right was TypeORM[0]. It was easy to get started with, includes consideration for migrations, allows you to use both the query building and annotated-class approaches where appropriate, also allowing for use of the repository pattern if you're comfortable with that, and has pretty great support for lots of different backends (I've used postgres the most though). All of this from a F/OSS project (~2 years ago I was also involved in a C# project during the switch from .NET 4.x to .NET core/standard and was very very annoyed that things I could easily do with TypeORM weren't available/worked out yet in EF core at the time).

[0]: https://github.com/typeorm/typeorm

Re: To ORM or Not to ORM

#66

Post by simplify »

frosted-flakes wrote: post #33
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 S…

What's wrong with working with plain arrays? Genuine question, they seem to work fine for me so far.

Re: To ORM or Not to ORM

#67

Post by stefanfisk »

dpcx wrote: post #64
megous wrote: post #59

Earlier quoted context omitted.

You don't need ORM for simple CRUD operations. All you need is a function you can pass a table name and a map of column names/values you want to insert/update.

Until you want to be able to sort and filter and do all of the other things that most CRUD applications do. Once you're there, if you're doing SQL directly, now you're manipulating strings in your code, instead of being able to build some kind of object that then generates a query for you.

It sounds like you are conflating an ORMs with query builders?

Re: To ORM or Not to ORM

#69

Post by macNchz »

dpcx wrote: post #64
megous wrote: post #59

Earlier quoted context omitted.

You don't need ORM for simple CRUD operations. All you need is a function you can pass a table name and a map of column names/values you want to insert/update.

Until you want to be able to sort and filter and do all of the other things that most CRUD applications do. Once you're there, if you're doing SQL directly, now you're manipulating strings in your code, instead of being able to build some kind of object that then generates a query for you.

Yeah if you’re doing lots of CRUD that approach quickly becomes an exercise in writing your own (bad, buggy) ORM.

Re: To ORM or Not to ORM

#70

Post by hyperman1 »

I recently put a lot of refactoring work in a java app. The enterprise architects made a list of decisions that amounted to forbidding an ORM, so a lot of JDBC/ResultSet boilerplate was included. The program had a tendency to UPDATE a few of the columns, then SELECT the same data right back a few lines later. Plenty of inconsistencies in the logic. This means refactoring went like this:

First step: Create for each table generic methods to insert, update,select all fields. Now at least memory and DB are consistent.

Next step: All these methods are mostly identical and there is a lot of commons-beanutils in there. So add an annotation to the relevant getters and generate most SQL statements on the fly.

Next step: Replace the incoherent commit/rollback mess with clear boundaries. Either it succeeds or it fails.

Next step: To stop the never ending reloads of data already in memory, SELECT data only when it's not already there. Flush all caches on commit.

All of this gives great results. Batch run time went down from 20+ minutes to a few seconds. Most weird crashes disappear. The need for manual data fixup after crashes evaporates. And then it hits me: I just wrote a custom ORM.

Post reply on HN