4 ms·
ObjectiveSync – A thin Java object persistence layer for JDBC (2015)
- xupybd 9y agoI think you missed the main issue I find with ORMs, it's near impossible to debug the SQL it's using. I really think they're an abstraction too far.
- monksy 9y agoChange the verbosity of the logging statements. They'll always output what SQL is going on.
- GordonS 9y agoActually, I've found it's generally quite straightforward to enable logging of the SQL executed by ORMs. What I have found difficult is trying to untangle the mess of inefficient SQL and coerce the ORM to doing what I really want it to do :/
- tomc1985 9y agoI think that depends heavily on the ORM in question. ActiveRecord's SQL can become nightmarishly complicated but the same query in DataMapper looks alot like what might be written by hand. ActiveRecord is way more expressive than DataMapper, IMHO, particularly if you want to make a fancy query GUI, and it's because of the additional abstractions it builds into its SQL generator.
- einrealist 9y agoIts not a big deal in Hibernate. SQL can be logged. You can intercept everything. And you can use sophisticated monitoring (e.g. New Relic's APM). To me, debugging with an ORM like Hibernate was never more complicated than debugging with the JDBC driver. Also, ORM implementations often contain multiple layers of abstractions, even co-existing ones (JQL vs. HQL). Personally, I don't like HQL / JQL. But it does a good job for simple tasks. For more complex things, I can write SQL and use just the mapping features of my ORM. I rather use Hibernate to get things done, than writing all the boiler plate with plain JDBC.
- chadgeidel 9y agoIt's fairly easy to do this in Entity Framework. Obviously if you have a giant query it's going to make some "optimizations" that you don't like but if you have a good understanding of your object model and how your database is architected you can usually create nice SQL.
- fusiongyro 9y agoThe real problem is that the object side is less abstract than the SQL side.
- philippeback 9y agoI always liked SimpleOrm https://berglas.org/simpleorm/index.html https://berglas.org/simpleorm/index.html It should be used more...
- jack9 9y agoThere's a similar PHP library called NotORM http://www.notorm.com/ http://www.notorm.com/
- justboxing 9y agoIn the Microsoft C#, .Net world, the solution already exists. Dapper => https://github.com/StackExchange/Dapper https://github.com/StackExchange/Dapper A thin layer on top of ADO.Net, blazing fast, provided for free courtesy the Stack Overflow team.
- deleted 9y ago[deleted]
- nickthemagicman 9y agoLaravel's Eloquent and Rails A.R. is infinitely better than raw sql.
- Xeoncross 9y agoORM's work great for CRUD. Then there is always that small collection of aggregation and reporting queries that take a few minutes to write in SQL and days to kludge together with an ORM and it's mostly-feature-complete abstraction layer over SQL (SQL is an abstraction layer).
- nickodell 9y agoWhy does this point to a github repo?
- sctb 9y agoWe reverted the title from the original “Why I hate Hibernate (and ORMs in general)”, which I assume is purely editorial. Submitters: please don't do this.
- deleted 9y ago[deleted]
- avodonosov 9y agoSpring + Hibernate is a sad example of extremely lame technologies dominating a whole language ecosystem.
- jacques_chester 9y agoSpring makes it pretty trivial to use JDBC or JOOQ or a variety of non-relational data stores if that's what you prefer. Disclosure: I work for Pivotal, we sponsor Spring development.
- avodonosov 9y agoBut absence of spring makes their usage even more convenietnt.
- jacques_chester 9y agoYou prefer handrolled boilerplate to JdbcTemplate?
- deleted 9y ago[deleted]
- mmmbacn 9y agoI've used this data modeling framework in Java that's similar to GraphQL: https://github.com/perfectsense/dari https://github.com/perfectsense/dari. I've found it leaps and bounds more productive than most ORM's and the debug tools are top notch.
- skrause 9y agoI never understand the argument that I shouldn't use an ORM because I "should not be afraid of SQL". No, I don't use ORMs because I'm afraid of SQL. I actually really like SQL and I'm good at writing SQL queries. But I still use ORMs very often because they help me with programmatic composability and with avoiding boilerplate. I mostly use SQLAlchemy ORM for CRUD applications. If I need to I can still drop down to SQLAlchemy Core or raw SQL queries, but those are rare cases. When I have to debug something I always just look at the generated SQL queries, most of the time they are actually quite readable.
- dorgo 9y agoUntil you do more than just CRUD. And your ORM's performance drop to zero. And you try to improve performance by circumvent your ORM and get bugs you need a week to debug. Because your ORM has a cache and by cirumventing it you introduced a discrepance between code and database.
- pmelendez 9y agoI do not know who downvoted but I support this... people don’t believe me but I have seen this exploding in production so many times that is not even interesting anymore
- hackits 9y agoWhen you have a cache, and even a resultset you're going to get discrepancies between your program state and the database state. If you need to maintain one side over the other that is where locking the records come into play. I find it a bit disappointing in the Java world owned currently by Oracle why the they haven't added extensions to the language so I can write bloody SQL statement and PL/SQL procedures naively in the language!
- NiceGuy_Ty 9y agoEh, not sold on native sql in a programming language. It doesn't take into account the different styles of databases, let alone the different sql dialects. I think it presents a similar problem as Scala's xml literals, which are now seen as language bloat especially since JSON has become popular.
- coding123 9y agoDefinitely agree with lots of the points in "not-so-great things" list. One fellow engineer ended up using Hibernate for more analytic queries - ended up causing so many strange issues. We discovered one of the queries was doing some kind of internal secondary query for each of the top-level rows. (So for each returning row fetched it was making another SQL query to the database). Not sure why it wasn't doing the obvious join, but I guess something broke its rules. So while I like hibernate for fetch, change, update etc.. I really think you need to be careful trusting it for joins and such.
- einrealist 9y agoAll these negative issues in this readme can be addressed when ORMs like Hibernate are used correctly. And some of the points are outright BS. Good ORMs make life much easier without compromising on quality and flexibility. Hibernate is more powerful than many developers expect. Many developers tend to see ORMs as magic and don't try to understand the tool they are using. To comment on some of the points from the readme: > What you get from Hibernate is not POJOs. Need for DAOs and copy, copy, copy. This is useless code and often breaks. Use generators to generate boiler plate, when possible. Write tests to... test! If you don't want a data access layer, then don't use an ORM. If you want a layer, you can model everything in a way that does not even expose the fact that an ORM is used. > Configuration too complex. You end up modelling everything around what works in Hibernate, not your classes (as promised) or what works in the database (that is the real constraint you are facing) Complex problems tend to have complex solutions. But, I certainly don't find Hibernate hard to configure (these days), even when the data model is complex. > Hibernate-aware code everywhere Can (should) be abstracted away. Use interfaces for describing entities and builders. Describe aggregated entities as Aggregates. Model query options as typed parameters. This way, the "boiler plate" becomes the contract for data access, without leaking ANY information about the ORM or whether a relational or non-relational data source / store is used. > Different query language without a reasonable shell - you have to write code to test out a query There are IDEs with good ORM support, like IntelliJ IDEA. Otherwise, write a little program or tool that runs the DSL against your code base. > Very complex and inefficient queries triggered for no apparent reason. You spend a day to control something that would have taken a few minutes in SQL I've seen complex and inefficient queries written in plain SQL. Usually, the ORM is much better at optimizing, if your data model is sane. If you have statements executed with no reason, then that's probably due to a bad design choice in your application. > Slow to start - big problem for testing. ORMs start pretty fast these days. For database initialization, I prefer Liquibase or Flyway over Hibernate's built in initialization. > Bad practice - if you hide the database, you may get something done quickly, but it's a bad idea. If yor Java code expects to have a collection of one million objects as an array, it does not matter if they are lazily loaded or not - some code somewhere might want to iterate over them, and this will kill the process. You cannot really forget that there is a database somewhere, and you should not do it. There are streams since Java 8. I use them to stream data from queries (scrollable ResultSet -> Spliterator -> autocloseable Stream). This really helps with the memory footprint. And because I abstract my data source / data store away, the source of the stream can be literally anything. It just happens to be a relational database that is accessed through an ORM. > Aborts on commit. For long-lived transaction, you never know WHAT made the transaction abort. And what can you do next? Who the hell event wants long-lived transactions today?!
- ssijak 9y agoRead about jooq https://www.jooq.org/ https://www.jooq.org/ Thank me later.
- oceanghost 9y agoORM is the Vietnam of computer science.