I am an author, speaker, and loud-mouth on the design of enterprise software. I work for ThoughtWorks, a software delivery and consulting company. Martin is a DZone MVB and is not an employee of DZone and has posted 80 posts at DZone. You can read more from them at their website. View Full User Profile

Martin Fowler on ORM Hate

05.09.2012
| 46775 views |
  • submit to reddit

While I was at the QCon conference in London a couple of months ago, it seemed that every talk included some snarky remarks about Object/Relational mapping (ORM) tools. I guess I should read the conference emails sent to speakers more carefully, doubtless there was something in there telling us all to heap scorn upon ORMs at least once every 45 minutes. But as you can tell, I want to push back a bit against this ORM hate - because I think a lot of it is unwarranted.

The charges against them can be summarized in that they are complex, and provide only a leaky abstraction over a relational data store. Their complexity implies a grueling learning curve and often systems using an ORM perform badly - often due to naive interactions with the underlying database.

There is a lot of truth to these charges, but such charges miss a vital piece of context. The object/relational mapping problem is hard. Essentially what you are doing is synchronizing between two quite different representations of data, one in the relational database, and the other in-memory. Although this is usually referred to as object-relational mapping, there is really nothing to do with objects here. By rights it should be referred to as in-memory/relational mapping problem, because it's true of mapping RDBMSs to any in-memory data structure. In-memory data structures offer much more flexibility than relational models, so to program effectively most people want to use the more varied in-memory structures and thus are faced with mapping that back to relations for the database.

The mapping is further complicated because you can make changes on either side that have to be mapped to the other. More complication arrives since you can have multiple people accessing and modifying the database simultaneously. The ORM has to handle this concurrency because you can't just rely on transactions- in most cases, you can't hold transactions open while you fiddle with the data in-memory.

I think that if you if you're going to dump on something in the way many people do about ORMs, you have to state the alternative. What do you do instead of an ORM? The cheap shots I usually hear ignore this, because this is where it gets messy. Basically it boils down to two strategies, solve the problem differently (and better), or avoid the problem. Both of these have significant flaws.

A better solution

Listening to some critics, you'd think that the best thing for a modern software developer to do is roll their own ORM. The implication is that tools like Hibernate and Active Record have just become bloatware, so you should come up with your own lightweight alternative. Now I've spent many an hour griping at bloatware, but ORMs really don't fit the bill - and I say this with bitter memory. For much of the 90's I saw project after project deal with the object/relational mapping problem by writing their own framework - it was always much tougher than people imagined. Usually you'd get enough early success to commit deeply to the framework and only after a while did you realize you were in a quagmire - this is where I sympathize greatly with Ted Neward's famous quote that object-relational mapping is the Vietnam of Computer Science[1].

The widely available open source ORMs (such as iBatis, Hibernate, and Active Record) did a great deal to remove this problem [2]. Certainly they are not trivial tools to use, as I said the underlying problem is hard, but you don't have to deal with the full experience of writing that stuff (the horror, the horror). However much you may hate using an ORM, take my word for it - you're better off.

I've often felt that much of the frustration with ORMs is about inflated expectations. Many people treat the relational database "like a crazy aunt who's shut up in an attic and whom nobody wants to talk about"[3]. In this world-view they just want to deal with in-memory data-structures and let the ORM deal with the database. This way of thinking can work for small applications and loads, but it soon falls apart once the going gets tough. Essentially the ORM can handle about 80-90% of the mapping problems, but that last chunk always needs careful work by somebody who really understands how a relational database works.

This is where the criticism comes that ORM is a leaky abstraction. This is true, but isn't necessarily a reason to avoid them. Mapping to a relational database involves lots of repetitive, boiler-plate code. A framework that allows me to avoid 80% of that is worthwhile even if it is only 80%. The problem is in me for pretending it's 100% when it isn't. David Heinemeier Hansson, of Active Record fame, has always argued that if you are writing an application backed by a relational database you should damn well know how a relational database works. Active Record is designed with that in mind, it takes care of boring stuff, but provides manholes so you can get down with the SQL when you have to. That's a far better approach to thinking about the role an ORM should play.

There's a consequence to this more limited expectation of what an ORM should do. I often hear people complain that they are forced to compromise their object model to make it more relational in order to please the ORM. Actually I think this is an inevitable consequence of using a relational database - you either have to make your in-memory model more relational, or you complicate your mapping code. I think it's perfectly reasonable to have a more relational domain model in order to simplify your object-relational mapping. That doesn't mean you should always follow the relational model exactly, but it does mean that you take into account the mapping complexity as part of your domain model design.

So am I saying that you should always use an existing ORM rather than doing something yourself? Well I've learned to always avoid saying "always". One exception that comes to mind is when you're only reading from the database. ORMs are complex because they have to handle a bi-directional mapping. A uni-directional problem is much easier to work with, particularly if your needs aren't too complex and you are comfortable with SQL. This is one of the arguments for CQRS.

So most of the time the mapping is a complicated problem, and you're better off using an admittedly complicated tool than starting a land war in Asia. But then there is the second alternative I mentioned earlier - can you avoid the problem?

Avoiding the problem

To avoid the mapping problem you have two alternatives. Either you use the relational model in memory, or you don't use it in the database.

To use a relational model in memory basically means programming in terms of relations, right the way through your application. In many ways this is what the 90's CRUD tools gave you. They work very well for applications where you're just pushing data to the screen and back, or for applications where your logic is well expressed in terms of SQL queries. Some problems are well suited for this approach, so if you can do this, you should. But its flaw is that often you can't.

When it comes to not using relational databases on the disk, there rises a whole bunch of new champions and old memories. In the 90's many of us (yes including me) thought that object databases would solve the problem by eliminating relations on the disk. We all know how that worked out. But there is now the new crew of NoSQL databases - will these allow us to finesse the ORM quagmire and allow us to shock-and-awe our data storage?

As you might have gathered, I think NoSQL is technology to be taken very seriously. If you have an application problem that maps well to a NoSQL data model - such as aggregates or graphs - then you can avoid the nastiness of mapping completely. Indeed this is often a reason I've heard teams go with a NoSQL solution. This is, I think, a viable route to go - hence my interest in increasing our understanding of NoSQL systems. But even so it only works when the fit between the application model and the NoSQL data model is good. Not all problems are technically suitable for a NoSQL database. And of course there are many situations where you're stuck with a relational model anyway. Maybe it's a corporate standard that you can't jump over, maybe you can't persuade your colleagues to accept the risks of an immature technology. In this case you can't avoid the mapping problem.

So ORMs help us deal with a very real problem for most enterprise applications. It's true they are often misused, and sometimes the underlying problem can be avoided. They aren't pretty tools, but then the problem they tackle isn't exactly cuddly either. I think they deserve a little more respect and a lot more understanding.

1: I have to confess a deep sense of conflict with the Vietnam analogy. At one level it seems like a case of the pathetic overblowing of software development's problems to compare a tricky technology to war. Nasty the programming may be, but you're still in a relatively comfy chair, usually with air conditioning, and bug-hunting doesn't involve bullets coming at you. But on another level, the phrase certainly resonates with the feeling of being sucked into a quagmire.

2: There were also commercial ORMs, such as TOPLink and Kodo. But the approachability of open source tools meant they became dominant.

3: I like this phrase so much I feel compelled to subject it to re-use.

Published at DZone with permission of Martin Fowler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jonathan Fisher replied on Wed, 2012/05/09 - 12:54pm

The problem with NoSQL solutions is that they've thrown the baby out with the bathwater... the baby being ACID guarantees and participation in XA transactions.

Yes ACID is unsexy and XA isn't "yeehaw RADICALLY SCALABLE" but there are only three companies with Facebook/Google/Twitter sized scalability problems. Those companies just happen to be Facebook, Google, and Twitter. The rest of us peons should be a lot more practical in our design decisions. 

Some really simplistic and beautiful designs can be built off of ACID and XA guarantees guarantees I'm completely ready to dump the traditional relational database when those concepts come to NoSQL.

Ricardo Zuasti replied on Wed, 2012/05/09 - 12:58pm

I agree with you on most of the articles topics, I would point out though that there are some ORM approachs I prefer over the others.

For example I find the iBatis (myBatis) approach cleaner and that it promotes a better code base than JPA/Hibernate. The "embracing" of SQL that iBatis does is a good thing in my book, it provides all the tools you need to ease the relational-memory mapping, while still forcing the developer to know his data structures and how the database works.

r. 

Wal Rus replied on Wed, 2012/05/09 - 7:42pm

iBatis and Hibernate appear different in approaching the problem. iBatis is a better solution than Hibernate, because iBatis scales well with rising complexity of schema. Hibernate and JPA in general do not scale well. Compex schemas are a nightmare to map.

Originally, one of the strongest (loudest) pro-ORM arguments was that developers did not need to learn 'complex' SQL and so forth.

Ironically, solution came with nightmarish HQL/ JPQL and Criteria API that are very, very complex and hard to learn, but, also, did not remove the need for knowing the SQL. 

So the original sentiment (SQL's complex, so lets create a simple abstraction) that led to the rise of ORM(Hibernate/JPA) is just that – sentiment. Not many people bring this up today, but this sentiment allowed ORM(Hibernate/JPA) to thrive and grow into a monster that it is today. 

No need to push against the ORM(JPA, Hibernate) hate, there is no hate. The solution just turned out to be

MORE COMPLEX THEN THE PROBLEM IT WAS TRYING TO SOLVE.

 iBatis took different approach, so putting it into the same basket with Hiberante is incorrect. 

Lukas Eder replied on Wed, 2012/05/09 - 1:07pm

Yes, "The Vietnam of Computer Science". I liked that article when I first saw it. Come to rescue jOOQ: "The Peace Treaty Between SQL and Java". Another "ORM" for those developers among us that actually want to use SQL and embrace the relational model rather than trying to hide and/or abstract it.

Fred Unknown replied on Wed, 2012/05/09 - 9:17pm

Woah!!! The world has come to an end.

Martin Fowler who I usualy consider as an influencial professional is now writting misinformed articles.

Where to start? There are just too many untruth and mis-information in this article - I cannot go over them all.

But for everyone interested in this topic. ORM does not work and will never work. I have 20 years experience in this field and have build some of the largest systems around where performance is paramount. I can tell you ORM cannot possibly work becuase it automatically means the access to the data will be much slower. This is not due to the incompetence of the dev involved but because of the ill conceived architecture of ORM. I have had the top engineers who build the ORM tools from the vendors telling me this.

The idea to conect an object graph in memory and a relational data structure is simply flawed. The network inefficiencies resulting from that approach are astronomical.

Moreover, ORM is based on a false premise - that SQL is hard. In fact SQL is simple. And for everyone out there interested in computer science. LEARN SQL. It is simple fast and cannot be replaced by anything else since it is a SET language to work on Set data. Replacing on standard Set language by a multitude of proprietary languages (one for each vendors) is of course silly.

And by the way - iBatis is not an ORM tool. It is actually a very good tool - this one works. It simply allows you to populate your objects from a result set.

Putting iBatis in the same categories as Hibernate only shows MF ignorance in this topic. I guess it is time to retire.

FB

Cay Horstmann replied on Wed, 2012/05/09 - 10:56pm

Thank you! I've been wondering why there aren't more nuanced ORM perspectives in the blogosphere. Yes, OR mapping is a hard problem, and using an OR mapper without some understanding what it does under the hood isn't going to be wonderful. Yes, if performance is paramount, someone out there can write better SQL or NoSQL than the ORM could. But there are an awful lot of use cases where reasonably savvy people use an OR mapper to save themselves a bunch of menial labor, and performance is just fine. It's a tool, not a silver bullet.

Robin Bygrave replied on Thu, 2012/05/10 - 7:55am

>> it automatically means the access to the data will be much slower.

How so? Surely the sql query execution is the majority of the total execution time.

 

>>  ill conceived architecture of ORM.

Seems to me that there are many ORM's with quite different architectures. What class/type of ORM are you referring to?  What is the architectural flaw?

 

>> The idea to conect an object graph in memory and a relational data structure is simply flawed.

How so? As I see it there is no difference here between pre-ORM client server tech and ORM's except they deal in Object graphs rather than tuples. What is the flaw?

 

>>The network inefficiencies resulting from that approach are astronomical.

With the ORM's I use the object graphs I'd describe as a 'disconnected snapshot' of the database data so I'm not sure what you mean by this. I wonder if you are talking about N+1 occuring or inefficient lazy loading? Can you expand on what extra network traffic this is?

 

>> Moreover, ORM is based on a false premise - that SQL is hard.

I don't think everyone would say that. Some might say the premise is more about being able to deal with object graphs rather than flat tuples.

 

I'd like to hear more details. 

Cheers, Rob.

 

Mirkus Mirkelinos replied on Thu, 2012/05/10 - 9:29am

>> But for everyone interested in this topic. ORM does not work and will never work. I have 20 years experience in this field and have build some of the largest systems around where performance is paramount. I can tell you ORM cannot possibly work becuase it automatically means the access to the data will be much slower. This is not due to the incompetence of the dev involved but because of the ill conceived architecture of ORM. I have had the top engineers who build the ORM tools from the vendors telling me this.

I've got more than 20 years of experience (not years passing by, but experience) and I've seen pretty large systems using ORM that worked. When it didn't work, it was mostly because the developers were too lazy to read the manual but that was it.

 >>Ironically, solution came with nightmarish HQL/ JPQL and Criteria API that are very, very complex and hard to learn, but, also, did not remove the need for knowing the SQL. 

 True, but just look at what we've got now: http://www.querydsl.com/ (type-safe SQL that allows refactoring and all).

Jammer Man replied on Thu, 2012/05/10 - 11:53am in response to: Fred Unknown

In your 20 years of experience you obviously haven't learned very much at all. I'd pick MF's opinion over some garden-variety d0uche troll like yourself any day.

Karl Peterbauer replied on Thu, 2012/05/10 - 12:00pm in response to: Fred Unknown

Granted, ORMs may not be the weapon of choice in very large and highly performance-critical missions. But for small and mid-range systems with moderate performance demands, ORMs are definitely a valuable tool. I'm happily using them for over a decade now (starting with TopLink in 1998, nowadays mostly JPA/Hibernate), and I never looked back on the old days of JDBC quagmire.

Mark Unknown replied on Thu, 2012/05/10 - 12:34pm in response to: Karl Peterbauer

" ORMs may not be the weapon of choice in very large and highly performance-critical missions"

 That does not mean they do not work. 

Mark Unknown replied on Thu, 2012/05/10 - 12:39pm in response to: Robin Bygrave

>> >> Moreover, ORM is based on a false premise - that SQL is hard.

>> I don't think everyone would say that. Some might say the premise is more about being able to deal with object graphs rather than flat tuples.

 What has been said is that SQL is more difficult to read and write than object queries. Typically this is in doing joins and poloymorphic queries.

Mark Unknown replied on Thu, 2012/05/10 - 12:45pm in response to: Fred Unknown

" And by the way - iBatis is not an ORM tool."

Ok so they call it a data mapper.  But it maps the relational model to the object model. That is what an ORM is.  

If you call a tail a leg, how many legs does a dog have?

I am not sure how many "ORMs" do, but I know Hibernate and NHibernate allow you to write your own SQL and use Stored Procs.  You also can just map tables to objects that effectively are table objects.

 

Karl Peterbauer replied on Thu, 2012/05/10 - 1:29pm in response to: Mark Unknown

Yes they work.

It's like claiming that Java "does not work" because the fastest web-servers on earth are written in C.

Ken Mah replied on Thu, 2012/05/10 - 1:13pm

Not agree!

In software there is nothing can be "hard". If any software wants to survive for long time then they have to be simple - soft. Histrory suggests that projects (like Hibernate) last only till the time better solution comes to market. One day someone comes with some better idea and then everything changes in a months. It takes very less time to throw products like Hibernate away. You are saying that ORM is trying to solve hard problem. Thats it. Thats what we are saying. It's hard. But it means there is still scope for imporvment (very big scope. may be we haven't even on right path). Before Unix, underlyaing problem was hard (hardest of all). Before C people thhought there was no way out but DR changed it. 

I can tell this with 100% gurantee that all people who have commented against Hibernate are still using it. I my self uses it. Why? Simply because it is hard to explain to our design architect. Second, may be we don't have another solution to tell to give to our architect. But important reason is, there is this craze in software world, using any software products which loooks good in theory.

Later in time if anyone calculate amount of time people wasted due to incompetant product of their time then he will simply laugh...or may be he will end up in writing good research paper on it. 

Just to clarify, we are not against ORM. That is not developer's job. It's researcher's job. We are agninst Hibernate/JPA. (iBatis is certainly best among them but sometimes I feel it is not fully supported ORM.). They have wasted so much precious time of people. And no need to talk about fustration.

And Hibernate people please stop giving that bullshit talk that people are not using it properly. We know we are not because now know we simply can't (just try using it once in very realstic Enterprise application).

 

 

Karl Peterbauer replied on Thu, 2012/05/10 - 1:40pm in response to: Ken Mah

They have wasted so much precious time of people.

That one hurts. Before ORMs it was a rule of thumb that 30% of the code of average projects were basic CRUD boilerplate. A new column for a table? Scan all your INSERTs and UPDATEs and add - say - the 20th '?' in the statement, add the 20th parameter at the right position, and cancel QA's holidays for a full regression test... that was a real waste of time! 

Ken Mah replied on Thu, 2012/05/10 - 2:26pm in response to: Karl Peterbauer

Agree but look at the next step which developer took in those day to fix it. Whenever people used to introduce such bug in the system they also used to spend 15-20 mins  (or 1 hour max) in finding that bug and fixing it. Because it was easy to find insert query, it was easy to find column and it was more easy to test and get solution (in short, most of them were were very silly typo kind of errors which even today people make with good IDE or framework).

But in today's ORM world, first we have to turn on some degubber (shoq_sql) to look for ugly kind of query (and so much query for one insert ;). You know what I'm saying right?), then write some JUnit to test my pojo (you will agree that without Junit how hard it is to test today's Hibernate code because starting server every time is simply not feasible). In short, spend some time on setting environment to test (may be one time activity but still complex because we do not just use Hibernate. We use other framework like spring, their test classes etc. etc. We have to worry about all other frameworks and along with it should work). After all this in some cases you have to worry about persitence of that object and detached objects, or whether mapping is correct or not, or lazy loading is enabled or not, why data is not going into slightly complex object like Map, List blah blah, how the hell second level cache works and how to make sure that it is indeed working as I'm expecting (I found no one to answer this question yet)...Common! such a big jargon for such a simple inset, update, select query. Using it just because it has SQL and not java. We have to agree that some tasks can't be done in Java (like browser side coding has to be done using HTML, JS. Similarly, backend must be done using sql. Just writing some wrpper to create sql query dynamically not an option). 

In short, even ORM's bug looks so much geeky or savvy that every time I fixed such bugs people start calling me geek.

Jose Maria Arranz replied on Fri, 2012/05/11 - 1:50am

Meanwhile something like: List children = parentObject.getChildren(); loads millions of rows or one query for every child object, the approach of Hibernate or JPAs regarding to relationships is broken.

Karl Peterbauer replied on Fri, 2012/05/11 - 11:46am in response to: Jose Maria Arranz

Simple rule of thumb: Don't explicitly model one-to-many-relationships in your entities, unless you have really good reasons to do so. Just model the many-to-one side. Provide a service method for resolving the children of a parent object. No sucking off half of the database, no lazy loading exceptions. Inconvenient sometimes, but hey: How would you do it without an ORM?

Karl Peterbauer replied on Fri, 2012/05/11 - 12:11pm in response to: Ken Mah

"Easy to find"? SQL statements are strings, thus one has to use textual search. JPA criteria in conjunction with metamodel generation allow type-safe, compile-time query construction. Unfortunately we don't have LINQ in Java, which simply blows the hell out of old-school tedious and error-prone query string concatenation.

JUnit testing for playing around with JPA queries? You might have a look at - say - Hibernate Console, which allows you to check your queries during development in a similar way like conventional SQL clients (or you might want to test your code anyway). And it's not hard to roll your own: A simple textfield for entering a JPA query, a service method for executing JPA queries, and a table for displaying the result rows, and voila: Play around with your entities in a running server...

Lost in the plethora of frameworks (Spring and friends)? Maybe you give JEE 6 a try. Define your entity with annotations and access them in a stateless session bean. No hassles.

Fred Unknown replied on Fri, 2012/05/11 - 4:53pm in response to: Robin Bygrave

Thank you for your reply - A lot of great questions so I decided to respond to them.

I'll try to provide more info to your questions.

>> How so? Surely the sql query execution is the majority of the total execution time.

Great question, really.

In a large system this is not so. As stated I only work on very large system, really large. So our ORM data (our object graph is stored on multiple servers as part of a federated gigantic cache if you will). The issue with using an ORM is that we access the data part of the object graph. Which of course is the point of an ORM. But to access the data we have to do a lot of graph traversal. This is very expensive as you can imagine in our scenario. Taversing an object graph can be much slower than using a SET language to query a Set data structure. Moreover, since our data can be on separate machine - you can also imagine the extra cost. Of course on top of that, accessing data is one thing. But often we of course have to chnage the data. Which now is a lot more cost prohibitive becuase all these chnages have to "percolate" through the distributed cache.

So in these large systems, most of the time is spent at the ORM level - traversing the object graph - even sometimes for very simple queries. The same query using a set language against the data directly is actually really fast (no graph traversal).

Someone, made a comment that for small and medium size system - ORM works. Yes it does. But even for a relatively small system. I am not convinced it really makes sense. Using something like iBatis makes more sense to me. iBatis is not an ORM, I am actually quite surprise some people think it is. The fact that iBatis help reducing the boilerlate code to access a DB does not make it an ORM. It simply helps removing all this silly code. And helps populate object from a result set. That is great and necessary.

>> Seems to me that there are many ORM's with quite different architectures. What class/type of ORM are you referring to? What is the architectural flaw?

Another great question, here is my quick answer. The flaw I am referring to is not in the implementation of the product but in its concept. To simplify a bit here - becuase a full answer would take too long. The issue of ORM is not the object mapping. But it is the R in oRm. In other words the relational mapping. It is this relational aspect that create the performance issues. iBatis is more focused on the OM part - in other words the object mapping. It simply helps populate an object from set of data. I am simplifying here a little bit but for the large part this is correct.

As developer we want to use ORM becuase we feel more confortable traversing object graph in a pure OO way than dealing with set data structure. I get it, it makes the data much nicer to deal with. But putting this data in a too OO way is often very costly. In large systems it is particularly true due to the performance issues associated with traversing these gigantic graphs. Instead when I keep this data in its set form, accessing it becomes much faster (most of the time 100+ times faster) (and easier too). This of course also means, I need to design a data access layer for these system a little bit differently. But the result is actually much simpler for the dev writting the code. In many ways it makes the business layer a litlle more "stateless" which also has the added benefit of simplifying all the transaction management of this large code base.

I hope this helps somewhat. Unfortunately I am not often reading this site so will probably not respond to further question.

ORM mapping is a real issue. I have not found yet anyone having really covered this topic in a pratical way based on real experience. It seems that most dev pretty much undertsand to stay away from it. But I am not sure they know exactly why.

I also would like to be clear - ORM works for small and medium size system. Unfortunately I do not get to work on these systems very often. Also, the less relationship is being mapped - the easier the ORM will be to implement and use. And the better it will perform.

At the end of the day, though, I think it is simpler to avoid a full blown ORM (hibernate, JPA, Kodo, etc... - I have used them all unfortunately.). Whenever I can now I use iBatis or similar approach.

I hope this helps somewhat clarify some aspect of my previous post.

Fred Unknown replied on Fri, 2012/05/11 - 4:58pm in response to: Karl Peterbauer

I agree.

You should take a look at iBatis or similar solutions. They are much simpler and lighter weight than JPA/Hibernate and Co.

They will help you remove the boilerplate code and keep your solution as simple as possible. Which is always a great objective to acheive in my opinion. Basically you will remove both the JDBC quagmire and the ORM quagmire.

Stephen Haberman replied on Fri, 2012/05/11 - 9:39pm

As an author of an ORM (Joist http://www.joist.ws), I have a biased opinion, but I think anyone who thinks ORM mapping is complex is doing it wrong.
Databases have primitives/scalars and foreign keys. Handle those two cases, and you have a good, simple ORM in <10k LOC. Try and do everything, like Hibernate/JPA does, and, yeah, you have a 100k LOC ORM.
If you can stay close to SQL, have a sane schema, and don't think you can take creative liberties when mapping the schema to your domain objects, I think ORMs can be pretty simple and easy to use.

Luca Garulli replied on Sat, 2012/05/12 - 6:27pm

OrientDB is trying to get this easy by supporting Object mapping natively: http://code.google.com/p/orient/wiki/ObjectDatabase. It's planned to support many JPA annotation to allow a soft migration from the Hibernate+RDBMS world.

One of most cool thing is the support for Object Oriented polymorphism at database level without impendence mismatch.

Robin Bygrave replied on Sun, 2012/05/13 - 8:57pm

>> our object graph is stored on multiple servers as part of a federated gigantic cache if you will

So you are using a large distributed L2 cache.

>>  But to access the data we have to do a lot of graph traversal. This is very expensive as you can imagine in our scenario. Taversing an object graph can be much slower than using a SET language to query a Set data structure.

Yes, it can be if you are invoking untuned lazy loading etc but it doesn't have to be - seems to me you are implying you can't do 'relational'queries in an ORM or that an L2 cache is required for ORM?

>>  But putting this data in a too OO way is often very costly. In large systems it is particularly true due to the performance issues associated with traversing these gigantic graphs. Instead when I keep this data in its set form, accessing it becomes much faster (most of the time 100+ times faster) (and easier too).

It seems like the way you are using ORM is via a large monolothic object graph (via a large distributed L2 cache). ORM doesn't mandate an L2 cache though or this approach, you can use the ORM to create small object graphs specific for the use case/transaction with just the information you need - much more like typically iBatis use.

>> ORM works for small and medium size system.

I guess if you use ORM to build/materialise really large object graphs and just walk them (invoking lots of lazy loading) then yes I can see that not scaling too well.  That said, you don't have to do it that way and I have not used ORM like that myself.

 

Cheers, Rob.

Jose Maria Arranz replied on Fri, 2012/05/18 - 1:13am

"A framework that allows me to avoid 80% of that is worthwhile even if it is only 80%. The problem is in me for pretending it's 100% when it isn't"

"I often hear people complain that they are forced to compromise their object model to make it more relational in order to please the ORM"

I agree, there are reasons to make something like JEPLayer

- Does not try to hide fully JDBC

- In spite of automatic binding between columns and object fields, manual binding is possible

- Reduce 80% of boiler plate, 100% is desired but is not worth the pain

Mehdi Heidarzadeh replied on Fri, 2012/05/25 - 3:36am

I like ORMs because mapping make developers life easier and reduce boiler plate code.
I remember designing a system using JDBC with tables that had 15 to 42 columns! that was a real nightmare.
And I remember designing an insurance system that was using Hibernate in a very large scale with many users! we were using Hibernate as ORM and it was Ok.


ORM affects performance but worth using it for many use cases.

Mirkus Mirkelinos replied on Tue, 2012/08/21 - 2:31pm in response to: Karl Peterbauer

I'm not in any way affiliated with queryDSL but I'll suggest it once more. Have you tried it? I find it much more easier than JPA2 type-safe queries and closer to LINQ.

Basil Abbas replied on Sat, 2013/07/06 - 9:36am

In my opinion, no library or framework will ever fix the ORM complexity problem. It will remain a headache for developers until something else is introduced .. a new DSL for describing entities supported by a new code generation tool.

We need a tool that reads entitiy descriptions, automatically creating all the java entities, DAOs, unit tests, database tables. Something similar to HEDL  although I believe HEDL is still in its early stages but very promising.

Code generation will allow the user to provide hints on how different fields in the object will be used and then DAO methods will be created automatically.


Victor Cerdeira replied on Mon, 2014/03/03 - 5:20am in response to: Basil Abbas

I'm agree that the best solution is to use a code generator.

I have written one, and I like to share it with you. You can find it at: 

http://www.softwaresouls.com/freezer/help/

It uses a DSL to describe the entities involved, and it generates the java DAOs, DTOs, database tables, and the HTML documentation.

Finally, it's easy to learn, and it can be adapted to change the content of the generated elements.


 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.