Discussions

News: Book Excerpt: JPA 101 Java Persistence Explained

  1. The Java Persistence API (JPA) was introduced as part of the Java EE 5 platform to simplify the development of Java applications using data persistence and to unify the community behind a standard lightweight persistence API. This chapter, excerpted from JPA 101, focuses on the Java Persistence Query Language (JPQL). It looks at the fetch join operator and delves into JPQL's bulk operation support. The JPA specification was based on the best ideas from existing persistence technologies but now provides existing Hibernate, TopLink and Kodo customers with a standard model for object/relational mapping. JPA 101: Java Persistence Explained is a fundamentals guide to the ins and outs of JPA, the Java object/relational mapping and persistence standard for both Java SE and Java EE applications. The book covers the basics of working with the JPA, JPA annotations, Entity Manager, JPA Query Language, and tools. As you work through the tutorial, you will build a simple Maven 2 project and Hibernate object model. Read the chapter on JPQL

    Threaded Messages (15)

  2. Yep... JPA is gr8 though hibernate has announced JPA compatibility.. Im using hibernate in its own. not with entitymanager sudhir nimavat http://www.jyog.com
  3. Will developers who left EJB for the POJO land of spring and hibernate, come back to EJB3 and JPA?
  4. Will developers who left EJB for the POJO land of spring and hibernate, come back to EJB3 and JPA?
    I thing they will leave Hibernate for iBatis :)
  5. There has to be a major reason for me to move to EJB and I am yet to be convinced. All the features of EJB 3.0 (ranging from POJOs and interceptors) are available to be through the use of Spring and other technology stacks (mainly AOP, hibernate, acegi and so on). I was listening to a podcast where the engineers at Sun where taking about Java EE and the cool new features..but i can't help think that they are abit too late. All the features that they are talking about are already available. Ok so those aren't from Sun but does it matter? There goes my chances of getting a job at Sun :-)
  6. The JPA specification was based on the best ideas from existing persistence technologies but now provides existing Hibernate, TopLink and Kodo customers with a standard model for object/relational mapping. Why?
  7. Why JPA Matters[ Go to top ]

    Great comments everyone, I would agree that some of the EJB 3.0 spec has been and is available in other frameworks, specifically Spring. However, the JPA does bring some new things to the table, most notably extended persistence contexts, the ability for a persistence context to live across multiple transactions. In addition, all JPA compliant persistence providers (Hibernate, TopLink, OpenJPA, etc.) now support a standard set of OR/M annotations so you can take your Hibernate mapping experience and apply it to TopLink without much effort. Before the JPA each provider had their own solution. I also think the JPQL is a move in the right direction. While the JPQL may not do everything HQL can do, it is a standard supported by all vendors, and many queries you may want to run day in and day out can be built upon JPQL. As for switching back to EJB3, I don't think you are going to see a lot of developers who've embraced the POJO world come back to EJB3 which is unfortunate because there are a lot of really good features in the spec and the programming model is so much simpler now.
  8. Re: Why JPA Matters[ Go to top ]

    In addition, all JPA compliant persistence providers (Hibernate, TopLink, OpenJPA, etc.) now support a standard set of OR/M annotations so you can take your Hibernate mapping experience and apply it to TopLink without much effort.
    apart from the fact that what is covered by JPA is a very limited subset of the mapping required by the vast majority of projects and do once you want to do something like have a List with indexes, or a real Map, then you get different behaviour between JPA implementations. Great eh?
  9. Re: Why JPA Matters[ Go to top ]

    Currently im very much satisfied with spring, Hibernate n all my pojos. Sudhir Nimavat http://www.jyog.com
  10. Re: Why JPA Matters[ Go to top ]

    You might be more satisfied with Ruby and Rails.
  11. Re: Why JPA Matters[ Go to top ]

    You might be more satisfied with Ruby and Rails.
    How so? Does Rails support AOP? Integrate with Quartz? Integrate with pretty much every persistence technology available? Integrate with LDAP?
  12. Re: Why JPA Matters[ Go to top ]

    Ah. Whiles we are on POJO based frameworks, did i hear anybody mention JBoss Seam?
  13. Re: Why JPA Matters[ Go to top ]

    You might be more satisfied with Ruby and Rails.
    A topic about Java persistence and a Ruby Glowstick accolyte chimes in. Nothing changes here.
  14. Re: Why JPA Matters[ Go to top ]

    Sounds like you feel threated by any thing new. No technology remains in the center stage for ever. I have been in java/j2ee world for a long time and I like it. But ruby/rails may be appropriate for relatively simpler projects.
  15. Re: Why JPA Matters[ Go to top ]

    Sounds like you feel threated by any thing new. No technology remains in the center stage for ever. I have been in java/j2ee world for a long time and I like it. But ruby/rails may be appropriate for relatively simpler projects.
    Actually no. I like new things. I responded to your post which simply said "You might be more satisfied with Ruby and Rails". You provided no reasons why the user should feel more satisfied (nor do you here either), and so its a glib statement that adds nothing to a discussion. The thread is about persistence. If you have something to add about how persistence is handled in Ruby that provides something beneficial to how it is done in Java then why not post it ? If you dont have something to post abotu the topic of the thread why not just read ?
  16. Re: Why JPA Matters[ Go to top ]

    However, the JPA does bring some new things to the table, most notably extended persistence contexts, the ability for a persistence context to live across multiple transactions.
    Even a Hibernate 2.1 session has the ability to live across multiple transactions. So what is the fuss?