Can Terracotta Dissolve The ORM Mismatch?
The short answer is: No. In many of your projects, you will still find the need of using RDBMSs. And there is nothing evil about RDMSs, as long as you use them for what they are good at, and for what they were designed. Ask a snail to move fast, you will be disappointed. Ask a RDBMS to persist an object graph, you will be disappointed. Hope that Terracotta brings some magic salvation? You will be disappointed, too.
Let us have a clear, un-biased view on the topic. I am not a fan of RDMBSs, of Terracotta, of Hibernate, not a fan of XML or binary data and a Lucene search index or any other particular technology. For me, they are the items in my tool belt. When I want to fix a picture at the wall, I use nail and hammer. When I want to paint, I take a knife and brush. So I do with the all the software techniques. When I need reporting and data-mining capabilities, I use an RDBMS, when I need to exchange data in a standardized format, I probably use XML. When I need a super-fast index, I use Lucene. And when I need all of them, I use them all together. I do not fight any of these techniques. Picking the right expert for the task, that’s the deal.
I am not a fan of the we-need-something-to-persist-let’s-take-an-RDBMS (as we always do) paradigm, and I am not a fan of an-RDBMS-is-always-evil attitude. What astounds me most is that so many programmers expect that there must be this one-and-only solution to persistence. Hence, it doesn’t exist – and it can’t.
About Relations and Object-Graphs
Relational databases once were a salvation and a relief to solve certain business problems. And in their domain, they still are. Object graphs on the other hand solve a different problem. It is naive to think that relational databases can be expected to persist such an object graph in a convenient way. We should be thankful for all the great ORM frameworks that make the impossible possible. We actually can map our object graphs to the relational model of a database. So why complain that there is still a leak, a mismatch, that the mapping is not perfect? How do you think this can be achieved? It can’t. That’s the truth.
I think – but this is just my decent opinion – we just don’t like to write that SQL boilerplate. It has nothing to do directly with implementing business logic (yes, that’s what we are told to get paid for), it is monotone work and extremely error-prone. So we do not like it, that’s all.
When it comes to ORM, you have the choice. Use an ORM framework and find a way to deal with the ORM mismatch and get things done, or complain and miss your project’s goals. I’d prefer the first.
Grid Computing Frameworks Might Save the World but Cannot Solve the ORM Mismatch Dilemma
There are some technologies arising that seem like premium candidates to solve the ORM mismatch dilemma. For example, the grid computing framework Terracotta, where you put all your application data into Java collection objects that are shared across multiple JVMs on multiple machines. Terracotta provides an easy and transparent way to persist these objects. And when you follow recent blog posts on that matter, Terracotta gets praised as the new technology with which you can kill your database. The people at Terracotta seem to make some fun out of it when they claim “Kill your database” on their own homepage. Though you might be too doped by the prospect of getting rid of your database, watch out for the link ”Before you kill your database” on the very same website.
Why should Terracotta be salvation for the ORM mismatch? How can you expect that? You must believe in miracles. Terracotta provides a persistence mechanism for shared application state data. When your store person data by an id as key in a shared hash map, how do you expect to find that object across you grid by first name or address? Terracotta solves the problem of high availability of shared application data. And just because they do that so elegantly that you as a programmer have not to deal with high availability persistence at all that doesn’t mean Terracotta is a natural solution to the ORM mismatch.
Analyze Your Application’s Data Model and Persistence Strategy
Before you make a decision whether you need a database, a Lucene search index or what ever persistence mechanism is available, analyze what will be done with that data. The reason so many programmers are sick of RDMBSs might have its root in that RDMS-fits-all approach. Analyze. Thoroughly. And when it comes to technologies like Terracotta, analyze even more thoroughly. Do you really want to spoil your shared memory with data of last year’s surveys? Or with the contents of unpurchased shoppings cart? What will you do with that data in memory? There are many strategies available, like evictors, caches and so forth. It is important to make the right decisions here to solve the problem of your projects domain. In one of my next blog posts I will give an deep insight into a real-life project introducing different persistence and caching strategies.
Stop Complaining About Mismatches
For specific computing tasks there are well-known and battle-proofed solutions. They are specialists. Don’t expect a specialist in one field to be able to deal with the tasks in another field or even excel at it, like a relational database being superman to handle an object graph. It is our job – our duty – as software developers to analyze the data model domain thoroughly and look for the best techniques available. Always looking for that one technology that makes all others obsolete is futile. We too often tend to put our efforts in just implementing the business logic and hope any super-wizard framework will handle the dirty parts like persistence or horizontal scalability for us. This is a delusion.
Make use of the frameworks available that can help you make the dirty work tolerable, use Hibernate and Terracotta and Spring and Lucene or whatever does the job. But don’t complain that there is still a mismatch you have to deal with. In the end, dealing with that mismatch is our job.
