Tuesday, December 2, 2008

Criticism of Java Persistence Frameworks

I have been working on persistence technologies for 8 years. I entered the persistence technology domain at my first company. We firstly used WebObjects’ Enterprise Objects framework (ancestor of all ORM libraries) for our projects in 2000. It was a very good framework and it was adequate for many persistence needs. We then began to develop our own web framework including persistence layer to make a software product to provide “fast application development for web applications” (this motto repeated across years in many places). After economical problems our project cancelled and then I transferred to another company in 2001 as Project Manager for developing new ERP software. I again take the responsibility of developing web framework for ERP applications. Its most important part is surely persistence layer. We developed the framework and used in ERP applications. As our in-house ERP software is developed and brought into use in many servers, our web frameworks matured and evolved. This is the journey that I am involved in persistence technologies.
During that time, EJB era ended and ORM frameworks popped. Many web applications emerged for the promise of fast or simple web application development. As our own development has continued across the years, I observed the emerging frameworks and inspected their documentation from books or articles. Let me share my thoughts about persistence solutions in Java world. Besides all criticism I state here, I appreciate the work and effort behind all these solutions. I know that it is very hard to bring these solutions into widespread use and support it.

It is a fact that we need a persistence solution. Most of applications are database-driven and need to access tables, modify data. Although there are many questions about persistence frameworks, we need them a lot when developing applications. Otherwise SQL codes scatter across applications causing an ugly and unmanageable application. Persistence frameworks build a database layer and separates concerns. Java Persistence solutions are divided into two branches. One is Java standard solutions; JDBC, EJB, JDO. The other is ORM (Object-relational Mapping) frameworks; Hibernate, Toplink, Enterprise Object Framework, iBatis etc.

Let me ask the basic question that everybody somehow asks himself “Isn’t there any other solution to persistence problem simpler and more powerful?” I have been reading many problem news about this issue. Last one was Sun’s attempt to simplify EJB. In fact, this is why new frameworks will never end. Followings are just some samples:

Instead of comparing every solution, I am going to describe most common pitfalls:

1- “Object-Relational Impedance Mismatch” was not solved appropriately:
This is the main problem. Everybody knows it but it still hasn't been solved completely. “Mismatch” is heavily lasting even in simplified-lightweight ORM frameworks. Is this inevitable? No, we can solve it but I think our attitude is wrong. We are trying to carry relational world into object world which will never occur. Objects and database technologies are different and should be left separate. For example, SQL is a very dynamic language that you can’t state it with objects. What we see is QUERY, JOIN, WHERE objects in ORM frameworks to re-implement SQL again in object world. We made this mistake in our first ORM framework but corrected in second one. The magical clue to achieve this is that not object-only or relational-only solution is true. We need a balanced mixture of those technologies by using objects when object usage is true and by using SQL when SQL usage is true. SQL abandonment is the major problem of ORM frameworks. Hiding SQL operations of persistent objects are problematic. This is why your favorite framework’s PersistenceManager class (source code) is complexity champion.

2- Frameworks didn’t suit application architecture needs (Web or Desktop):
Your persistent object model should be compatible with your application architecture; application event system, application GUI components, application flow or navigation. I wonder how much rich applications will be succeeded using current persistence frameworks. I am still skeptical about using those frameworks in complex applications. Maybe it is succeeded but could we maintain with minimal cost? Are transaction boundaries, transaction rollbacks, data validations, lazy loading mechanisms are running without problem? Across the years, I still see the same demo a simple data list and simple command buttons to add/update/delete records (Where is grid, detail grids, tabs, detail tabs etc?). That is not the applications we are trying to develop, we are expected to develop much more complex applications.

3- XML usage should be immediately abandoned:
SQL, Mapping and descriptions are held in XML files. This is the most bleeding mistake done through the years. When annotation is added to the Java, eventually XML files are abandoned. Why do we need adding another touch-point for developers decreasing development speed? Couldn’t we add them to the persistent classes without waiting annotation support? Edit hundreds of XML files without any real benefit. I remember that one of persistence solution documentation says that transaction boundaries flexibly determined via XML files. Who needs flexible transaction boundary changes, I don’t need any. Who need flexible mapping? I don’t need any. Could you change your fragile application without touching any code? Impossible. Field change is flexibly done. Does anyone remember field name or type change doesn’t change application code?

4- Database Metadata was not utilized:
Before going to database, persistent classes should validate its data. This is not the case for many persistence frameworks. We had developed generic validation rules that are executed every time when user enters data like type, range, format, length, security (i.e. SQL injection) control. Any specific validation rules can be added to persistent objects similar to database table constraint rules. There are many other usages for metadata. In some of persistence solutions, there is no API to access to metadata of persistent objects other than database metadata.

5- Object Query Languages are a wrong path:
For the sake of removing all SQL statements in objects, OQLs are invented; EJB-QL,HQL etc. Many classes are written to handle this new query language. Why do we invent a new language even though we already have SQL? I think the reason for that mapping SQL resultset confuses ORM object caches and make them same with ordinary objects. Let’s reinvent everything for OQL; syntax, access plan, index optimization etc. We don’t need this. If we need some changing criteria, basic Criteria API’s are enough for that.

6- SQL visibility is important:
SQL is here and will be here in the future. SQL is tried to be removed completely from persistence solutions (Named Transparent Persistence Framework). SQL must be contributed much more than its current use. SQL has its standards (Ansi 92 SQL) that should be enough for database independence if it is removed for the sake of database independence. If you want to use custom SQL, your trouble begins. SQL usage should be made simpler in persistence frameworks. It is very hard at the moment.

7- Multiple data source dilemma:
One of the major architectural problems of persistence frameworks is multiple data source architecture. This is why we still discuss inabilities of the persistence frameworks today. Small percent of possibility to use different data source added enormous cumbersome to the persistence frameworks. What are the data sources other than database? File, Network, EIS, XML, ESB, JMS etc. I don’t answer the question why we don’t leave this portion of problem to the other software. I think it is a rare condition and should be totally removed from persistence solutions. This will not endanger its generality.

8- Why persistent objects are so weak (POJO)?:
We were asking opposite question years ago for EJB “why EJB objects are so heavy?”. Today the question is converted. I think this is mainly caused with the aim of hiding generated code. I think there should be a middle way. Persistent objects may take much more responsibility. They may take validation responsibility, value object responsibility etc.

9- Poor Transaction Management:
Visibility of objects entered to transaction is questionable. When reading a piece of code, it is very hard to understand transaction borders if it resides in a XML file that you forget to read (Declarative Transaction Demarcation). We use automatic transaction management for mapped child objects freeing programmer to start and commit transaction for them. Is object state handled correctly (according to application needs) in commit or rollback condition? Is transactional memory footprint is manageable? Transactional memory is a very big problem when thousand of objects participate in a transaction. Is isolation level adjustable according to application needs?

10- Heavy Object Caches:
Object caches are subject to debate. Aren’t database buffer pools enough for caching? Garbage collector troubles when memory is loaded with many objects. Why do we reinvent database cache system again with object caches? Yes, it is sometimes useful to cache objects in bulk object creation but if it is a part of system, isn’t this responsibility of database system?

11- Wrong Locking Methods:
Using database locks for application lock needs is another pitfall. Since some processes require many screens and steps, to lock records across long processes leads to performance problems. Optimistic locks and pessimistic locks are still a missing feature. We also implemented optimistic locks as transparent which doesn’t require explicit API call.

12- Persistence API could be simpler:
I do not like API used for the persistence. JPA is candidate to solve this problem. To do simple database operations, we need to write many boilerplate code; Sessions, UnitOfWork, Context etc. Add your UI object to this list, DAO, DTO, value objects etc. Why do not we give this responsibility to persistent objects? I really don’t figure out why transaction mechanism is not used for the session architecture. I think this is why many scripting or domain-specific languages (DSL) are emerging for the simplicity.

DBEmployee dbEmployee = new DBEmployee();

dbEmployee.dbSave(); // inserts record here

13- Bytecode manipulation problems:
We know from JSP technology that runtime code generation and compilation is very expensive. When we add persistent objects to this bandwagon, our software system stability is at stake. Changing an object after its declaration at runtime or build-time may cause many problems; performance, testability, stability etc. Many of us already experienced JITC problems which it has similar mechanism.

14- Unnecessary OID (object id) columns in tables whereas PK columns are enough:
This is the behavior of some persistence framework that your DBA never agrees upon. Many frameworks can’t handle multiple PK and FK keys. This is a very big handicap.

15- Inheritance has no meaningful usage:
Wrong motivation is that; “In object world, inheritance is a great structure so we must use it in relational world.” You don’t need inheritance in relational world. We don’t implement inheritance in our ORM solution and we don’t even need it. Traversing your persistent object one level below is not a hard job. Even your tables may already have some repeating redundant columns.

16- Primary and foreign keys are held in accompanying new classes causing many unnecessary classes:
When considering 1000 tables in our ERP system, applications have many persistent objects. If we had created PK and FK classes, it is going to be a total mess. We used simple strings for the solution of problem. I see in some frameworks PKs and FKs are held in their own classes.

17- Missing cluster support:
Many leading Application Servers support cluster, but to use cluster with persistent objects would not be easy. First of all, sequence generation and locking system should support cluster. I am sure that to write clusterable persistent objects would not be easy. Every application doesn’t need cluster but as your application grows than scalability and availability concern increases than cluster becomes necessary.

18- Missing database events:
Like triggers in databases, we sometimes need database event support, like row inserted, updated, deleted. This is especially required if you want to add support of BPM or Workflow to your application.

19- Missing authorization:
Row-level authorization just recently added to the feature list of ORM frameworks. Database connection users also can be separated according to user roles for security.

20- Missing dynamic rules:
Some validations or calculations may change over time and can’t be stated with static code or parameter. Persistent objects should support dynamic rule engines or mechanisms.

21- Missing object modeling tools for code generation:
Most of ORM framework have mapping design tools. Reverse engineering from database tables are a common feature. We should design objects and generate persistent objects from this design models.

22- Missing audit trailer:
In ERP systems, audit trailing is a very important requirement. Because of this reason, every table includes columns like insert time, user inserted, last edit time, last user edited etc. There should be ways to fill these columns or other helper tables transparently without appending to SQL statements by programmers.

23- Missing persistent object debugging utilities:
Persistent objects state (insert, update, delete, identical) should be visible. At runtime, sometimes persistent objects need to be accessed to read last SQL executed or field values. Instead of attaching a profiling software to production system, some debugging information should be provided.

This is like a wish list and may be used by persistence framework developers. To build a persistent framework is very charming and looks like very easy but as you progress it requires a lot of resource. To justify your development investment, resources should be evaluated carefully thinking all the risks that your attempt may not produce result. Your initial framework will be used and then changing and evolving it be a real nightmare if you are not familiar with concepts and followed the wrong path.


Luxspes said...

Object-relational impedance mismatch is not solved, not it will be solved, perhaps because the problem is that even Sql is fully relational, and it is full of flaws, so nobody really knows how the Object-True Relational impedance mismatch actually looks (or if there is one).

Yes, sadly frameworks are generally built to solve simple "demo" problems, but no one teaches you how to use them to build real world applications.

I hate XML usage too, annotations can do pretty much everything XML use to do, but even annotations are over used this days, how come, for example JBoss Seam needs them a lot, but Wicket needs none, and has a cleaner programming model? More like WebObjects used to have.

I think the problem with database metadata is that SQL databases are not really standard, why do I say that? because so there is no real way to metadata information in a portable way between databases. JDBC tries to, but it comes short.

Yes OQL is the wrong path, what we need is an Industrial D.

Sadly I disagree with you, I need to throw away SQL, and start using a really relational language, even Tutorial D will suffice.

I do think it would be nice to be able to speak to different datasource using and unified truly relational language.

Yeah, POJOs are too weak, I really miss the days when I programmed in NeXTStep EOF, those were real Enterprise Objects, not like those anemic POJOs, and not like those bloated EJB, but lately I think that the answer is in something truly relational, like Alphora Dataphor.

I agree with you on locking, it is a major headache, and most people use it wrong, or plain do not use at all, and end up having lots of concurrency or performance problems.

Yeah, the current persistence API are too complicated, and when they are not, then they are too incovenient, we need something simpler, and more powerful.

Who needs bytcode manipulation? what we need is a truly relational language with extended metadata, like Alphora Dataphor that can pretty much generate all the User interface from the database, with really strong data valiation.

I disagre on OIDS, I think complex primary key are overused, and currently they are hard to deal with, even with plain relational programming.

No need for inheritance, I agree, but we need a way to avoid violating DRY when we define databases.

Taylor said...

I think your post is spot on - but it seems to me that the root of the problem is not the ORM or even the object - relational impedance mismatch. Those are but symptoms of the deeper problem...

Rather, it seems, the propensity to shove everything into the database is what is hurting you. You mention problems with OIDs, events, locking, and so forth. Those problems seem to stem from having an application programming model that doesn't know where it should reside - is it data driven and is controlled by the database, or is it model driven and is controlled by the programmer? The problems you list stem from having your finger in both pies at the same time...

Fundamentally, objects and data are different, even if people want to dress up data to look like objects, you will have a mismatch, and get all the problems you list. EJBs, ORM, and the like tries to mask these issues, and they can do so for a class of problems - but not when the model or the application gets beyond a trivial amount of complexity.

Isn't there an easier way? Yes, I believe so. The only reason you rely on the database so much is for persistence and queryability. Most programmers can live without the latter, since a rich programming language gives them everything they need - for proof watch a programmer when he tries to figure out HQL. He'll be crying out for a HashMap in no time.

So is the database just about persistence of your objects then? For many people, yes. And there lies your solution.

If you strip away all the symptoms of the problem, and focus on the root problem, you'll find what you are looking for is a better way to provide persistence for your object model. While there several such solutions, I am biased and believe that Terracotta gives your object oriented model persistence without all the complexity and difficulty of JDBC, EJBs, and ORM, or in other words, without all the headache. Furthermore, Terracotta doesn't wreck Objects in the process of persisting them, you get the full power of an OOP language, with threads, locking and a rich object graph without having to worry about the nastiness that gross hacks in the past such as RMI and Serialization have imposed.

teyc said...

Fundamentally, database stores are too weak to hold business rules. RDBMSes still deals with VARCHAR when everyone else have moved on to strings.

However, you are quite right that we can make use of a lot more metadata in the data layer, be it in the RDBMS or the POJO layer.

I have started cataloging them here.


I'll be combing your post for more, if you don't mind.

Ivan said...

Excellent points and probably the best summary on the web as to why ORM just doesn't cut it.

mnuttall said...

Other than point 8 (which has nothing to do with ORMs) totally clueless and wrong. I am sure some ORMs don't cut it but some do. I'll try to come back later and post a point by point reply. Keep that day job as a PM.

mnuttall said...

1.“Object-Relational Impedance Mismatch” is not solved - I really don't get what the point is. ORMs help you deal with the mismatch. The good ones do it well. The only way to get rid of it is to make one side be like the other.
“SQL abandonment is the major problem of ORM frameworks”. What? I am not aware of any that don't either use or generate SQL.
“Hiding SQL operations of persistent objects are problematic “. Maybe in some. I use Hibernate. I don't see the issue.
“This is why your favorite framework’s PersistenceManager class is complexity champion “ No idea what this means.
2.Frameworks don’t suit application architecture needs (Web or Desktop) - They don't? I use ORMs in web apps and desktop apps. I use the EXACT same layer in applications that have web and desktop user interfaces.
“I wonder how much rich applications will be succeeded using current persistence frameworks “. I don't need to wonder. They work.
“I am still skeptical about using those frameworks in complex applications “. I'm not skeptical. I use them in complex applications and they work.
“Maybe it is succeeded but could we maintain with minimal cost? “ Yes
“Are transaction boundaries, transaction rollbacks, data validations, lazy loading mechanisms are running without problem? “ Yes. Use the Springframework.
“Across the years, I still see the same demo “. Most demos of pretty much anything are pretty lame
3.“XML usage should be immediately abandoned “. Not all mappings are held in XML. Hibernate lets you choose. Sometimes XML is the better choice. If you deploy your domain objects to a Desktop client you probably don't want your db mappings in Annotations. Sometimes you need to override the annotations. Sometimes you need different mappings for other clients.
“Who needs flexible transaction boundary changes, I don’t need any. Who need flexible mapping? I don’t need any. “ Then you are not doing anything complex.
Does anyone remember field name or type change doesn’t change application code? Table and Field names I have.
4.Database Metadata is not utilized: So? The Metadata is generated from the Mappings.
“In some of persistence solutions, there is no API to access to metadata of persistent objects other than database metadata. “ - http://www.theserverside.com/news/thread.tss?thread_id=52092
5.Object Query Languages are a wrong path: Really? Have you written a complex query in HQL or JPQL and then see what is generated?
“Why do we invent a new language even though we already have SQL? “ because we need to query objects, not tables.
6.Don’t throw SQL away, it is not enemy . It is not thrown away.
“SQL has its standards (Ansi 92 SQL) that should be enough for database independence if it is removed for the sake of database independence. “ DDL is not standard. And the ANSI standard is not enough. For instance, sequence ids and identity key retrieval.
“SQL usage should be made simpler in persistence frameworks. It is very hard at the moment.” Maybe in some. Not in JPA or Hibernate.
7.Multiple data source dilemma: Pick a good ORM. Hibernate has shards. Then again, maybe the framework is not the problem. It could be your architecture. I am not sure what the rest of your point is.
8.Why persistent objects are so weak (POJO) : Because most developers are, at best, average. I do agree on this point and do implement business logic in my pojos. This is not a ORM issue.
9.Poor Transaction Management: I use Spring. I don't see the problem.
10.Heavy Object Caches: “Object caches are subject to debate “. Sure it depends on your application needs.
“Aren’t database buffer pools enough for caching? “ Sometimes. Sometimes not.
“Garbage collector troubles when memory is loaded with many objects. “ Yes. So load objects intellegently or use something like Coherence or Terracotta.
“isn’t this responsibility of database system? “ No. The database is relational and it is more expensive to scale at the database. Sometimes it is the right choice for some cach ing.
11.Wrong Locking Methods : This is not an ORM only issue. ORMs help you deal with it better though.
12.Persistence API could be simpler . Sounds like you have an architectural issue. This is not the fault of the ORM.
13.Bytecode manipulation problems. This is a straw man argument.
14.Unnecessary OID (object id) columns in tables whereas PK columns are enough: Define unnecessary.
“Many frameworks can’t handle multiple PK and FK keys. This is a very big handicap. “ Which ones? Hibernate can.
15.Inheritance has no meaningful usage: What? I thought you had a complex system.
“We don’t implement inheritance in our ORM solution and we don’t even need it “. I do and I need it. So either you are wrong or have simple needs.
“Traversing your persistent object one level below is not a hard job. “ What does that have to do with Inheritance?
16.Missing cluster support: Really? If you need it, get it from a vendor who has it.
“I am sure that to write clusterable persistent objects would not be easy. “ Of course not. But not using objects would be more difficult.
17.Missing database events: If you need db triggers, use them.
“Like triggers in databases, we sometimes need database event support, like row inserted, updated, deleted. “ Have you looked at Hibernate?
“This is especially required if you want to add support of BPM or Workflow to your application. “ LOL. Yeah no one is doing this. This should not be done at the persistence level anyway.
18.Missing authorization “Row-level authorization “ ORMS don't deal in rows. Hibernate gives you the ability to emulate this in an object way.
“Database connection users also can be separated according to user roles for security. “ I am sure this can be useful. But db connections are expensive and need to be pooled. Authorization needs to be handled at a higher level as sometimes the user is no longer connected when the db is accessed on their behalf.
19.Missing dynamic rules:
This is not the job of the ORM.
20.Missing object modeling tools for code generation: They exist if you want to use them. They are a niche tool and don't work for many people. Otherwise they'd be selling like hotcakes.
21.Missing audit trailer: See Hibernate Envers and AOP.
“...transparently without appending to SQL statements by programmers. “. Another architectural issue and not an ORM issue.
22.Missing persistent object debugging utilities . Use Spring and/or AOP.

Michael Kimsal said...

I'm not fluent enough (yet) in all this (legacy?) javaspeak, but am wondering what y'all think of GORM, and to what degree it addresses many of the issues raised here. It seems to me that GORM addresses many of the issues, but would like some feedback from others.

Joris said...

I totally agree. You should checkout rails and some of the following plugins:


Brian said...

The only criticism I have regarding your criticism of Java persistence frameworks is that you assume SQL is the only way to access a relational database. It is a common misconception that SQL and "relational" are synonymous. There are different ways of accessing relational databases and some frameworks hide SQL because the underlying database doesn't support it.

My primary criticism of most Java persistence frameworks is that they are hardwired to only support SQL databases. Once they do this the points you raise about hiding SQL make more sense, but only in context.

andy said...

The majority of your comments seem to have little basis in reality, but anyway I'll respond to a few ...

3. All leading persistence specifications/frameworks allow either XML, or annotations, or a mix. Use what you feel most comfortable with. Why exactly is that a problem to you ?

4. Many implementations can validate persistence data up to a point. JDO 2.3 has an API for metadata access.

5. Object query languages are a perfectly valid path. Yeah you like to use SQL, good for you. If you're using an OODB then it makes no sense. All leading persistence specifications/frameworks support both interchangeably. Users can pick which they prefer. Is that a bad thing?

6. Who said SQL is the enemy? You obviously love it, so good for you. Others like a refactorable query language, and others like an object based language to query their ... objects. See 5 above

7. Referring to data federation ? Some frameworks are available for this

8. Persistence objects are whatever you want them to be. Persistence specifications don't limit what you put in there. That is an architectural decision, so quit blaming the persistence tool.

9. Persistence specs have a very clear transaction support. This is typically local txns and JTA txns, with most providing full XA support. This is exactly what the persistence specs should define. Everything beyond that is an architectural issue

10. L2 caches are there for performance, and are optional in all persistence specs. Use it if you want, or not. Whats the issue again ?

12. How much simpler can an API get ? pm.makePersistent(obj) ? You can do this within a txn, or nontransactional if you want.

13. What problem is there with bytecode enhancement? You have no (coherent) argument there. Tools are available in all build envs for doing post-compile enhancement, or runtime enhancement.

14. Both major persistence specs (and their implementations) support application-identity (use of fields in the class to map to the PK). There is no surrogate column with that. Please do check your facts here.

15. All persistence specs provide several inheritance strategies for ORM. You could just map a class to a single table and be done with it. Users choice. Flexibility. The issue ?

16. PKs and FKs in separate classes? Huh?
If you have a composite PK then you typically need a PK class (separate or inner) but no persistence solution i Know of asks you to do that for single field PKs, nor any FKs. Facts?

Persistence specifications cater for all users ways of working not just yours. The features you want are in the main specs and frameworks. Just because they also have many other features (for non-RDBMS datastores) is no reason to dismiss them.


fando.angband@gmail.com said...

Regarding the impedance mismatch problem, I have a feeling the fundamental issue is programmers wanting to work with objects since that's what the favorite languages and development environments support.

What if we had a high level language that had both classes and special structures that represent data from a relational database? Is there such a thing?

mnuttall said...

JDO supports persistence store other than RDBMS and query languages other that SQL

Robin Bygrave said...

There are a lot of good points here.

There is an ORM that I would argue is simplier to use/understand than JPA/JDO.

- It has automatic query tuning
- A Simplier query language (based on object graph construction)
- Full support for partial objects
- Uses JPA Annotations for mapping
- Makes full use of database meta data (yes you do need to take into account DB differences here)
- Has no EntityManager/PersistenceManager (not session/unitOfWork based) making the API simplier to use and understand.

Check out Ebean at http://www.avaje.org/

Cheers, Rob.

andrew said...

If you know some Python, you should try using SQLAlchemy. It is very impressive and manages to address many of your concerns (in particular, it uses database metadata and has a very nice way of generating SQL from within Python).

However, I don't agree with your comments on XML or caching. I recently developed a system with iBatis and was very impressed. First, it is fairly simple. Second, the XML allowed me to migrate quickly from a dev database on MySQL to a production database in Oracle (while keeping SQL operations like AVG over GROUPs that are more efficiently done in SQL than in Java). Third, I had very fine control of caching (the simplicity of iBatis helps here as it doesn't force you to have large graphs of objects in memory, which complicates caching) which really saved my skin when the client decided to put the database on a machine with only 4GB memory....

andrew said...

PS I discuss iBatis caching more at http://www.acooke.org/cute/iBatisORMa0.html (it was a "learning experience" - you need to read all the entries to understand the final approach, I think!) and the project in general is described in http://www.acooke.org/kpi.pdf (which is perhaps a better summary, but covers more of the system so is less detailed).

(Alex) said...

just to put it on your map:

I could write what's usually written in a promo piece :) but i won't :) because, usually it takes more than 5 minutes to figure out a framework. In the case of JDBCPersistence it'll take 15 (could not resist a little promo:) – Simple and open.

Markus Plesser said...

Metadata handling, event based scripting, integrated security and versioning support, etc ...
Don't want to write a promo as well, but you might want to check out [fleXive] (http://www.flexive.org) ;-)

acorona said...

Persistence frameworks can be simple. Back in Smalltalk we developed a persistence framework that made it easy to persist objects just as you suggest. We then ported that framework and approach to Java so we have something like:

Employee employee = new Employee();
employee.setName("My name");

//To remove

To make this possible we used an intrusive approach which required you to extend a base class from which you inherited most functionality. This framework is still available and is called JGrinder and new version JGrinderX.

Queries, we implemented them using Query by Example, which is easy to use for people used to just code to objects. But for people used to SQL then it may be too much work, so here is were things get tricky about frameworks...do we handle all possibilities or we handle some and let you decide what else to do once your requirement exposes a limitation of the framework. At which point you'll need to look for other technologies and solutions such as OODBMS (Versant, GemStone, db4o, etc.) or distributed caches such as GemFire...

Reindeer said...

I absolutely agree with your criticism and you are not alone.

While simply storing away and retrieving objects in and from a relational
database might be sufficient for some simple applications, when it comes to
fully utilize the power of a relational database for example when building
complex dynamic queries featuring aggregation and transformation of data is
required, ORM solutions fail – simply because the entire approach is unsuitable
for these kind of tasks.

And yes XML mappings should be immediately abandoned. I never understood how
anyone could have possibly come up with that idea in the first place, nor do I
understand why anyone ever thought it was a good idea. Unfortunately annotations
aren’t any better. Both XML mappings and annotations are not part of the
solution but rather part of the problem.

But believe it or not, there is hope. There is a persistence solution available
that allows you to build complex dynamic queries in code – absolutely string
free and without the need to learn a new query language – giving you exactly the
SQL you want. A solution that does not use XML mappings or annotations but uses
java classes to represent the data model. A solution that offers save and easy
metadata access and even lets you add extra application specific metadata. A
solution that is lightweight, configuration free and works completely without
bytecode manipulation. And a solution that offers applications a much higher
degree of integration and thus a much better separation of model and view.

The persistence solution I am talking about is called Empire-db, its Open Source
and it is currently in the Apache Incubator. For more information see

For everyone interested I especially recommend the article “What's
wrong with Hibernate and JPA
” that can be found here:

andrew said...

empire-db looks very nice (and it looks a lot like sqlalchemy - i hope you are learning from them instead of repeating whatever mistakes they've made along the way...)

Thomas Hobbes said...

If you hate ORM so much, stop using relational databases at all:


Stick with pure objects, this will solve your impedance problem...

Sombunall said...

Your post makes me think you have little experience with persistence and even less knowledge about ORM frameworks. Some, but not all of them, are created and extended by people to solve their real everyday problems. And most, but not all, of one's persistence problems get solved by a capable ORM solution.

Ibrahim Levent said...

Thanks for valuable comments. I know some ORM frameworks already have solid solutions for some of these problems. Besides, I don’t target any specific solution or framework. My criticism is general and includes Java standard solutions. Most of criticism items are based on ERP(most of them uses RDBMS) development experience and doesn’t include Non-relational or Object-oriented DBMSs.
I believe that current solutions will get better that is why I make this blog post.

Ibrahim Levent said...

Published on TSS: