6 ms·
A long time ago, I designed and created an ORM for Java. I brought it to a startup and we made some money selling it. One of the key features was that it went a
by geophile 6y ago
A long time ago, I designed and created an ORM for Java. I brought it to a startup and we made some money selling it. One of the key features was that it went a long way to solving the N+1 problem, which was a unique feature at the time.
Obviously, I bought into the whole ORM concept, but I did have doubts in the back of my mind, some of which showed up in this article. You have to retrieve all of the columns needed to constitute an object. There is no subtlety in controlling the SELECT clause. Getting object identity right is hard, (e.g. you don't want to distinct Customer objects representing the same real-world Customer just because you ran two queries that happened to identify the same Customer). Caching is hard, especially when there are stored procedures doing updates and your ORM has no insight into them. Sometimes it would be nice to just write the damned SQL. Schema and/or object model changes are difficult, because you need to keep the two in sync. When I wrote my own database applications, I didn't want an ORM, not even mine. I wanted to write SQL. Having some tools to manage PreparedStatements and Connections would have been nice, but for my own work, I really preferred writing my own SQL.
But what finally changed my mind completely about ORMs was a hallway conversation with a developer at a prospect on Wall Street. (I think it was one of the firms to go under in the 2008 crash.) She told me that her resume looks a lot better with "5 years Oracle experience", than with "5 years XYZ ORM experience". This, combined with the doubts that were accumulating in my mind, finally pushed me over the edge.
In later years, playing with various web development frameworks, I dreaded dealing with ORMs. It's as the article said: I don't want to learn yet another query language, only to have that translated, badly, into SQL. Just let me write the damned SQL, it isn't that hard. I know exactly what SQL I want to run. Why should I create work for myself in convincing the ORM to do what I already know how to do?
- coldtea 6y ago"One of the key features was that it went a long way to solving the N+1 problem, which was a unique feature at the time." In case someone else is wondering: https://stackoverflow.com/questions/97197/what-is-the-n1-selects-problem-in-orm-object-relational-mapping https://stackoverflow.com/questions/97197/what-is-the-n1-sel...
- okareaman 6y agoThank you for this. It's a time saver for a lot of people. Yesterday someone was throwing around "HKT" without definition. Wikipedia disambiguated it into 5 different things, none of which applied. I figured out it was Higher Kindred Types in Haskell, but imagine 10,000 people all wasting 5 minutes like I did.
- valenterry 6y agoWhen talking in the context of type-systems, this is a common abbreviation though. I agree that it is annoying, but at some point you have to learn abbreviations. If it was in a different context, then it would have probably been better written out though.
- okareaman 6y agoIt was in the context of Rust async being broken https://news.ycombinator.com/item?id=26406989 https://news.ycombinator.com/item?id=26406989
- geophile 6y agoThank you, I should have included a definition or link myself.
- chopin 6y agoIt however should be noted that JPA can run native (SQL) queries and even lets you map the result onto entities if those are a fit for the result set. I've used that with success even for partial results (not all columns selected). It's just not typed but that is true of JPQL as well. And the criteria API is, well, ...special.
- Cthulhu_ 6y agoHonestly the main reason I still use an ORM right now (Gorm, it's not the best), is to solve a number of annoyances I would otherwise have (and I may yet switch to straight SQL): mapping result sets to structs, updating relationships (treating nested objects as a single document), and database migrations. I really don't mind SQL, I mind all the perceived boilerplate around it.
- marvinblum 6y agoThere is sqlx for that: https://github.com/jmoiron/sqlx https://github.com/jmoiron/sqlx
- geophile 6y agoYes, exactly. When I write SQL applications now, I usually start by implementing a little database interface to take care of the boilerplate. The application can then provide SQL as needed.
- deleted 6y ago[deleted]
- stickfigure 6y agoI use everyone's favorite punching bag - Hibernate - a lot. I write all my queries in... SQL. It works pretty well this way. The "ORM/SQL dichotomy" is greatly exaggerated.
- geophile 6y agoYou seem to be in agreement with the article and my top-level comment, since you aren't using the Object/Relational Mapping part of your favorite ORM. It is not surprising that the ORM/SQL dichotomy is exaggerated if you ignore the ORM.
- stickfigure 6y agoI make queries in SQL and those queries are mapped to objects. Sounds like ORM to me. Furthermore, those objects are "live" and editing them updates the database. Navigating the object graph navigates the database. All this is very convenient. When it's not convenient or performant, I write updates or tuple queries by hand. But mostly the approach of "select entities using complex SQL queries but use the ORM approach afterward" is a sweet spot.
- ryanjshaw 6y agoI believe it depends on what problem you are trying to solve. Surprisingly nobody has mentioned this in the thread, but domain-driven design (DDD) encourages you to split your problem domain into different bounded contexts (BC) and use the right architecture for each BC. Classic example is an event booking system: (a) Event Management is basic CRUD, so you use an ORM everywhere. There are no complicated queries here so ORM objections don't count. (b) Ticket Management has multiple users, race conditions, performance requirements, etc. so maybe go the command-query separation (CQRS) route and use a full ORM for your write model and raw SQL, possibly a micro-ORM, for your eventually-consistent read model. Why use a full ORM? You get to write your domain logic in your high level language with full unit testing, and the ORM worries about mapping this back to the database, dealing with concurrency and retry strategies automatically. For this to work you have to carefully design your business transactions against small aggregates containing a handful of entities, which is difficult to get right initially but has many advantages. (c) Payments/Refunds are transactional, reliant on external services, and need a full audit history so maybe consider an event sourced approach with no ORM visible. (d) Reports have no write model, so an ORM holds little advantage. Use SSRS, Power Bi, QlikView, etc. etc.
- valenterry 6y agoThere is also the alternative of not using classical OOP but a functional style, where your types map much easier to what is in your database. Then you still use a tool to write in your language so that it is typesafe, but otherwise there is no magic mapping.