ORM is a nice acronym to throw around but people got the impression that it does more than that. Not having to learn SQL... What is that even supposed to mean? You still need to know how to write queries in an ORM. Most ORMs come with very nice query builders for that reason. I personally enjoy writing dynamic queries for extended search functionality. Supporting 3 dozen different fields to filter is much easier when you don't have to concatenate SQL or use boolean flags to toggle individual clauses of a huge static SQL query.
Yeah they do suck at reporting, performance and supporting old organically grown schemas that weren't designed with the limitations of your ORM in mind. Whenever I need to insert thousands of rows, it's much faster without the ORM. I've never thought, oh the last 10% can't be done with the ORM, throw the entire thing away. Just be pragmatic and do what is most effective. I personally am tired of writing raw insert/update/delete queries that only touch a single row. For me there is nothing to be gained by not using an ORM when you can.
My biggest pet peeve with JVM ORMs is that they don't work with GraalVMs native image feature. They create proxies and use reflection. I want a good out of the box experience so I don't use native image very often. It's a shame.
Are ORMs leaky abstraction? Yes. All non-trivial abstractions are leaky.
Can you write 95% of code in ORM and drop to raw SQL for 5%? Yes.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
>The SQL language is meant to abstract away the procedural steps that are needed to query a database
Leaky abstractions, all the way down?
And that is find when you have more than one application using the database, but, if you are the only one using it, then likely you should change it until it does.
In our team we typically use noSql for databases with single applications, and SQL for ones where we have a lot of applications hanging off the same database.
Just because it means we can match what the application is doing and the database closer.
You can use a combination of JPQL, native SQL, and object mapping. There's nothing stopping you from mixing and matching.
You can use an ORM to save entities, and using native SQL to retrieve projections, Spring Data makes this easy, as it will do the mapping, if you provide an interface.
This has been the best that I've encountered myself.
Then got on some ORM using projects and hated them. Joins were painful. I had to learn a new syntax which seemed really dumb when I already knew SQL so why the need to add a layer of complication on top?
Over time I got used to it. Recently inherited a project that didn't use an ORM. Tons of stored procedures I have to go look up. Tons of "on the fly" SQL with string concatenation (yes including the potential for SQL injection because author was apparently unaware you can't just take raw user input safely into your SQL strings). And it's just ugly the whole thing. String concatenation with a bunch of "if" statements.
A fan of good ORMs here. But wasn't always, it was a conversion.
One case where I still think ORMs like SQLAlchemy make a great sense is in open-source software than can be configured to work with different databases (lime SQLite/Postgres/Maria).
If you own the entire stack and can control what FB the software is used with, fine, but it can be worth trading some performance to flexibility.
If you really do want to support multiple databases, you need to write code with all of them in mind and test with them, not just leave it to users to find all the bugs when they change the DB driver to something no-one else actually uses.
I run a large number of open-source software privately. It would be a way smaller number if I couldn't use them with Postgres.
Many users and projects will start on sqlite but as they mature migrate to clustered instances of a hosted database. It's great that this can be supported without each project implementing every DB.
I have been the user hitting a bug (which I was able to submit a fix for) in the scenario you describe. I much prefer that to not using the software at all or setting up a MySQL instance.
I‘m probably just not knowledgable enough on how to use e.g. Hibernate „correctly“ but modeling any entity with inheritance was a recipe for disaster at some point. Also Collections and Hibernate were an incredible pain.
DB stuff is not the thing I‘m very good at (as probably gleaned from my comment) but even pretty basic stuff kind of fell apart pretty fast at any sort of non-hobby scale. At the same time I dread handling transactions and de/serialization more manually…
Then a bunch of non-specialists said "we don't want to use more than one language" and came up with some hacks to write DB queries in languages that were never designed for that. The hacky stuff actually ends up generating the proper query language behind the scenes, poorly.
One would wonder why would anyone prefer the hacks, but the appeal of using one language for everything is strong. This is also why DSLs never took off in general despite promising to significantly lower the cognitive load due to being a better fit for the problem domain. At least with most DSLs there are usually additional reasons not to use them: the implementation is usually not as good as the popular languages. This is not true for SQL, and yet is suffers from the same problem.
Not having to specify the mapping between business objects and a SQL database is massive value on it's own. Having not only the ability to avoid doing that, but upon making changes to your objects, being able to migrate the database easily is frankly amazing.
I wish people were more open to learning more languages. A good DSL can be amazingly expressive. But you are correct in pointing out that gluing languages together is a pain, and it's a good reminder. Lesson learned ;)
Another advantage is that you type-check your queries, whereas with pure SQL you can accidentally load a number into a string variable and crash the application.
Because of this I prefer very light ORMs that abstract almost nothing. Those that provide model definitions, automatic migrations and a one-one SQL mapping.
An IDE that understood SQL would probably mitigate almost all opposition and yet nobody came up with one after all these years. So I guess the standard DSL defense doesn't really doesn't work.
All right, point taken, I'll take my downvotes and go home :) I don't use an IDE and most people I work with don't either. But this is a useful reminder that the world can be very different outside of one's bubble.
Any particular recommendations? I tried hibernate in java and was put off by complexity.