• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
Sheriffs:
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
Bartenders:
  • Mike London

Spring in Action - JPA and Hibernate

 
Ranch Hand
Posts: 148
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
At University, I had email client type of project assignment and I was the best in my class, as professor pointed out. However, I was using bunch of tutorials and blogs on how to use and persist data using Hibernate.

Since we all know that Hibernate is an implementation of JPA, my question for you is, can a beginner using your book, understand JPA well enough so he/she can further deep dive into Hibernate.

In what style do you teach and display usage of JPA (or Hibernate)?

And maybe a bit broader question, what would be your tip or strategy on how to tackle "the beast" (not counting buying your book haha just kidding)

Cheers!
 
Saloon Keeper
Posts: 26541
187
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a 2003(!) edition of Spring in Action, and even back then there was a topic on Hibernate with Spring (Spring Data). It was only a chapter, and JPA has entire books devoted solet to JPA itself, but it's a start.

One thing I should note, though is that Hibernate "isn't" JPA. Hibernate is older than JPA and was a contributor to the JPA standard. So now there are two types of Hibernate: Legacy Hibernate and Hibernate JPA. They are much alike, but they are not the same.  Spring supports both versions of Hibernate. As well as other JPA products such as Apache OpenJPA. And by extension, EJB, since JPA is a subset of the EJB 3 standard, although Spring Data aspires to do "EJB" better than EJB does.

I mention the difference because an awful lot of people ask questions here on the Ranch and they're using Legacy Hiibernate. Likewise, if you go searching the web for "Spring Hibernate", you'll probably find both versions. I don't recommend legacy Hibernate, since to the best of my knowledge JPA does everything the original Hibernate did and it's likely that Legacy Hibernate will eventually become unsupported. But in the mean time, make sure you know which flavor of Hibernate you got your code samples from. And nothing lingers on the Internet like obsolete information, except maybe for outright lies. But that's a different story. I spent years admonishing people not to use obsolete JSF constructs.
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll be brutally honest...I'm not a huge fan of JPA (or ORM in general). When I first learned ORM (anybody remember Castor?), I thought it was amazing. I could map objects to table and properties to columns and it was like magic! Except that it wasn't magic...I still had to define the mapping. And what I learned from all of that is that I'm pretty good at writing SQL, but I'm HORRIBLE at defining mappings...especially if the database schema deviates (as it often does) from the domain model. Therefore, although I still do some JPA from time to time, I would prefer JDBC (well, Spring's abstraction of JDBC) over JPA any day.

That said, if you must do JPA, then there's no way to avoid the mapping. It's just so essential to JPA. Therefore, since I can't eliminate mapping pain, I seek ways to reduce pain in writing repositories. Before Spring Data JPA, I observed that all of my repositories, regardless of the domain, looked pretty much the same. My repositories were just thing wrappers around EntityManager and had (more or less) the exact same methods. I hated it. But if I'm going to do JPA today, then Spring Data JPA is the way to go. Let Spring handle all of the EntityManager stuff and just write a repository interface. Easy-peasy (except for the mapping stuff).

So yeah...my book covers JPA using Spring Data JPA. What's nice about that is that the programming model for Spring Data JPA is nearly identical to working with Spring Data Cassandra, Spring Data JDBC, Spring Data MongoDB, ... etc. There are subtle differences, but for the most part, once you know how to work with one kind of database with Spring Data, it's easy to apply that know-how to another kind of database. And, in fact, the book will cover Spring Data JPA, SD-JDBC, SD-MongoDB, and SD-Cassandra.
 
Tim Holloway
Saloon Keeper
Posts: 26541
187
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Craig just doesn't know how to have fun. ORM/JPA is not only fun, but productive. Benchmarks have shown that using an ORM can sometimes be twice as efficient as raw JDBC, even as (counter-intuitively) modern compilers can be much more efficient than assembly language when you scale up.

Besides, ORMs virtually eliminate the dreaded SQL JOIN. Which is worth something all by itself. A whole lot of something.

If Castor was part of Lutris, then yes, I remember it, although that was so long ago I don't remember details. My first industrial-grade introduction fo ORM was via Kodo JDO (before Oracle bought them). When the JPA standard came out, Oracle re-worked it into Apache OpenJPA, keeping many of the original team members to support it.

Which, by roundabout way of saying that if you detest doing ORM Entity field-mapping in bulk, OpenJPA has tools to map from existing databases automatically.

Just about all forms of database access are tricky. You not only have to maintain transaction contexts, you have to ensure you don't release resource leak resources - a common fault in manual JDBC code is skipping the close() of JDBC objects if they get thrown. Spring deals with that automatically and it abstracts and encapsulates transaction management as well, which has allowed me to create a very productive and reliable 2-level persistent data architecture that I use routinely.

And, incidentally, in addition to JPA, Spring Data works quite well with the Neo4J graph database. It also supports things like MongoDB for your NoSQL needs..
 
Craig Walls
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tim: In no way am I judged anyone who likes ORM or suggesting that you shouldn't use it. There are obvious benefits and, as I even stated, I am known to use it from time to time. I just don't enjoy it much when I do.

But yeah, Spring Data is amazing for ANY kind of persistence, whether it be JPA or JDBC for relational databases, MongoDB, Neo4j, Cassandra, Redis, etc, etc, etc, etc, etc. And there's so much more you can do with it beyond just creating repositories. I'm especially a big fan of Spring Data projections which take query's response and "project" it onto an otherwise completely unrelated type that just happens to share some of the same properties. What's more, if you look closely at the queries that are executed for projections (at least when query logging is turned on for JPA), you'll notice that the queries are optimized for what's needed in the projection. E.g., if the entity has 10 properties, but it's being projected onto an object with 2 properties, the query will only fetch those 2 properties and disregard any unnecessary joins. It's really quite awesome.

 
reply
    Bookmark Topic Watch Topic
  • New Topic