JPA: Pros and Cons posted on 08 Apr 2011 20:25
OK, first of all, some preliminaries… I'm currently working on some crazy Java EE project that defiles and denies almost every rule of Software Engineering and Computer Science put together. But I'll write about it some other time =)
Today I'm gonna talk about JPA 2.0 — Java Persistence API 2.0 — based on personal real-world experience. If you don't know what JPA is — see Wikipedia about it. I just want to share some thoughts I have on the subject.
Do not use JPA when you already have an extensive domain model
That was our first big mistake when we decided to go with JPA. We were (and still are) bound by a Big-Domain-SQL-Model (BDSM) that tries to imitate NoSQL on a MySQL DB — and does it WRONG. We have to simulate some pretty crazy SQL logic using twisted rules of BDSM and JPA gets in the way:
- No JOINs between entities without JPA mappings — our BDSM does not have any foreign keys, is too big to fully map it to JPA entities and has some «context-sensitive» mappings that simply cannot be expressed in JPA. Stuff we can say in SQL we cannot say in JPQL, and that sucks.
- Composite primary keys are a pain. Face it, and learn to live with it.
- Lazy fetching is evil. Nothing beats it when you detach an entity from your JPA layer hoping to get a fully initialized object and get some «super-efficient-lazy-meta-fantastic-proxy» instead.
Now I really wish that we'd use something closer to iBATIS that is «down there with SQL» — thus, closer to BDSM.
Do not count on different JPA implementations to be compatible
As a matter of fact, they almost certainly are NOT compatible. For example, the above-mentioned example about detaching an entity with lazy fields — EclipseLink initializes them on detachment while Hibernate does not (I have yet to find who's right from the JPA 2.0 spec PoV).
Or when you're using <delimited-identifiers/> option with EclipseLink — it does work. When you use it with Hibernate — it cannot find any tables because table names are quoted (e.g. «`Person`»). And that — I must repeat myself — sucks =)
I'm not saying that EclipseLink is better than Hibernate — my point is that even if you use only pure JPA 2.0 in your application — you cannot switch between implementations as easily as you'd like to. Just accept that and move on.
There is no error reporting in JPA
This is what … well, what pisses me off like hell. I know I'm not perfect and that I make mistakes when I code. I make mistakes in my JPQL queries. But I have yet to find an error message that actually says something even remotely related to what caused the error. When JPA says that «You're trying to register the same query twice», it almost certainly means that the problem is somewhere else. Pretty neat, huh?
The only workaround we found is — test ALL of your queries on deployment. Use a special deployment-time-only bean that triggers them and ensures that they (somehow) work. If queries fail — you'll have a very limited set of changes to review and analyze. And do not try to understand the error message =)
Entities are nice
OK, finally some pros =) Working with entity classes (when you forget about everything I said before) is nice. No nasty SQL — just some objects you can pass around and write back to database whenever you want it. I'm no SQL wizard — and entity classes remove a huge pain in the butt for me =)
Annotation-based configuration is very nice
I hate XML configuration. Spring and its XML hell can kiss my ass goodbye =) I don't see the point in separating code from configuration — configuration rarely changes after deployment, XML is very prone to mistypes and is painful for your eyes. That is why the fact that I can configure almost everything via annotations is great. Pa-ra-pam-pam-pam — I'm loving it =)
So — that's all I want to say today about JPA. I've got sooo many other stuff I wanna share with whoever is reading this, but — some other time, mate =)
PS This review is very biased and expresses my personal opinion on the subject. I may very well be wrong about some points =) I hold no responsibility for the mistakes in your application design and implementation that you make after reading this post =)
Comments: 2 : Rating: 0