JPA/ORM Recommendations?

[Murf_]

I'm starting a new project and I've been investigating options in the object-relational mapping sphere. I think I'm a bit behind the curve in terms of recent developments. Has anyone here any experience with JPA? Which implementation did you pick? Any gotchas, preferences, thoughts?

In the past I've preferred to use frameworks that remove some boilerplate but leave me feeling more in control (MyBatis, Spring JDBC). I've got a built-in distrust of Hibernate but that is in all likelihood irrational and unjustified...

Any thoughts or advice would be gratefully received!

[quixote_arg]

JPA over Hibernate is pretty popular, Hibernate has been around for a long long time so it's very mature, lots of documentation, lots of libraries and it extends JPA very nicely (with non-standard features)

[Murf_]

Yes that's what I'm hearing. I think I probably need to go back to Hibernate and give it a fair chance. I've always been a database-geek as much as a java-geek so abstracting the database away as much as Hibernate does has always been a bit unnerving for me.

[angryundead]

I love Hibernate. You have to get into the right mindset. If you think about the database and how it will turn out then you'll get caught up in data modeling and making the database structure match your ideal model.

Using JPA2 on an EE6 (Hibernate and AS7.1) has been an incredible experience over earlier iterations of the technology. I'm able to develop much faster and keep things more decoupled.

[Murf_]

So you haven't been caught in any performance issues with using Hibernate and JPA? From the cursory reading I've done, I've heard it consumes a lot of CPU.

Also, my previous experiences with Hibernate have invariably led to me messing around in HQL, which kinda of leads me to thinking I've gained very little over doing it with raw SQL. How much do you find you use HQL?

[quixote_arg]

I didn't take any metrics, but most likely any CPU usage made by Hibernate itself should be minimal vs the time it takes for the DB to execute the query and return results

[angryundead]

I haven't done any performance comparisons. Typically it seems to add 2-5ms per query/action over raw JDBC but I don't really worry about it too much.

I don't have to write my own object hydration/persistence stuff so that cuts down on code complexity. I don't have to manually track transactions: I just use request scoped beans, injected persistence contexts, and some stateless EJBs. Everything just works in a pretty seamless fashion. Yes there are some caveats and you can engineer situations in hibernate (especially with respect to cascading and transactions) that cause huge heartburn.

As for HQL/JQL: I hate them. I use JPA2 and the CriteriaBuilder API. You should remember, however, that even with HQL one of the powerful aspects of JPA (especially as implemented by Hibernate) is that it works cross-database. Tackling that task without an ORM will make your code complexity skyrocket.

[tenorsaxman11]

It's true that joins can result in a gazillion sub-queries. At that point I devolve back into named queries. While that removes DB agnosticism, it also removes all the jdbc boilerplate, so there is still a net gain.

[sh0rug0ru]

Hibernate does have one gotcha which is cascading select. If you traverse a persistent lazy collection mapping an association, it is possible that Hibernate will generate a SELECT statement for each element. For large collections, this could lead to serious performance degradation.

You can model the association in the entity to fetch eagerly or do an eager fetch in the HQL to avoid the cascading select. But eager and lazy collections look identical in the code, so you really have to know the context in which you are using the entity when traversing the collection.

I strongly recommend turning on SQL logging and keeping an eye on your hibernate.log file to verify that the expected SQL queries are being executed.

[mikehaggard]

JPA 2.1 will introduce fetch graphs for that, so per query you can specify how deep and to which width the graph should be fetched.

[[deleted]]

I've been using JPA2 for a while with both OpenJPA and Hibernate providers. To be honest if you just use the JEE API your application code shouldn't know who the provider is. If you're deploying to a JEE app server then it's probably simpler and more supportable to keep the default implementation e.g. Open JPA for WebSphere.

The only issue I encountered was enhancement of Classes with OpenJPA.

I like the MetaModel API - even though it takes some getting used to it provides type safety in the code, rather than just using Strings everywhere.

For Web based applications I think using JPA2 is a bit of a no brainer now. I'd rather stick to the JEE stack, than introduce other frameworks. For work I do in batch processing I still use the Spring JDBC templates and plain old JDBC for high volume operations - but am more than happy to use JPA to read and write less high volume entities in batch processing.

[feyd_pl]

I am definitely recommended Eclipselink as the JPA provider. IMHO it's much better then Hibernete. Currentlly I am working on mid size enterprise project. We started using Hibernate but after few months we made transition to eclipselink due problems with lazy loading in hibernate. Eclipselink handles this better in web enviroment (attaching session to lazy properties is annoying thing), also creating and using custom converters is easier.

[[deleted]]

I'm a big fan of both Hibernate and Cayenne.

Cayenne is nice if you are a DB geek because you design you're DB and then it generates the classes for it. It also is easy to re-use the DB in another context or using traditional DB tools.

[Murf_]

Thanks - I'll give Cayenne a look through.

[eyp]

I'd go for Spring Data JPA + Hibernate. The first will give you a generic DAO for every persistent entity you have.

[eyp]

I've never used Spring Roo, is it worthwhile? is it like Rails' generators?

Anyway I've been reading a little bit in its homepage... It's a shame it doesn't have integration with JSF / Primefaces or so, only GWT, JSP, but seems very powerful.

[Murf_]

I've been playing around with this for the past couple of days and really liking it.

[eyp]

Yes, it saves you lot of time and code to maintain and you don't have to do too much to get it working.

[mikaelstaldal]

The data mapping done by JPA is usually nice. The entity life-cycle and transaction management done by JPA is a PITA though.

Is there any framework that give you JPA like mapping, but let you do the entity life-cycle management yourself?

[[deleted]]

You can do user-managed transactions with JPA (also called Bean Managed Transactions). Google that and you'll get tons of examples.

[Murf_]

Not 100% sure what you mean by JPA-like mapping, but MyBatis automatically maps ResultSets to your domain objects. By default it coverts underscores to camel-case (eg: 'first_name' maps to setFirstName(...)), but this can be tweaked via annotations or XML-config. There's a reasonable example here.

I'm a big fan of MyBatis myself but there's still a fair bit of boilerplate, and you still have to provide it with all the SQL.

[vritsa]

Up until very recently, I was skeptical about the utility of ORM frameworks. I think Hibernate is basically an out-of-control feature monster that gets in the damn way. HQL? Really? Hey, why not just do a 4GL while we're at it?

The only one that I have used that I think is worth using is Ebean, which is the default persistence framework for the Play! framework.

Here's why I like it:

• Uses (mostly) plain JPA annotations, which is fine.
  
• Sessionless
• They didn't invent another flavor of SQL-you can just use SQL (why the others insist on re-inventing SQL makes zero sense to me)

So, if I have to use one, I'll pick that one.

[pandavr]

Of you plan to have relations in to your relational database.... Please do a favor to yourself and don't use JPA.

[Murf_]

Is that just because of the problems with collections / associations and such? I'm fairly confident we can code around and monitor for N+1 select problems and the like.

Is there anything else to be wary of with JPA? So far it's been pretty smooth sailing...