6 Replies Latest reply on Sep 17, 2009 12:09 AM by luxspes

    To JPA or To Hibernate?

    hubaghdadi

      Hi.
      I'm trying to create a Seam application (JavaBeans and Hibernate), I use Seam's hibernate2 sample application as my guide.
      I decided to go with annotations this time and give hbm files a vacation ,so I annotated my domain objects with the usual annotations (@Entity, @OneToMany, @NotNull .....)
      I also use @NamedQueries annotations and inject Hibernate Session into my JavaBeans.
      But after a while it seems to me that I use JPA, not Hibernate!
      I'm now really confused, should I supply hibernate.cfg.xml or persistence.xml?
      Thanks.

        • 1. Re: To JPA or To Hibernate?
          christian.bauer

          1. You posted this already on the old Seam forum, no duplicates please.


          2. Go here for Hibernate questions: http://forum.hibernate.org

          • 2. Re: To JPA or To Hibernate?
            jarkko

            Taking this as an important question I'd like to share some of our experiences.
            Simply put, having just EJB 3.0 JPA is just not enough. We find it that in many situtations we need to revert to entityManager.getDeledate(). But this works! And we've chosen to take this path. Use JPA, and revert to 3.0 EJB API (yes, the naming is a mess :) when required.
            Hopefully we'll be more to the standard side, but still be able to use the full power Hibernate when needed.


            What's bothering me is that the Seam Wiki example has taken the full Hiberante route.. ;)


            • 3. Re: To JPA or To Hibernate?
              grettke_spdr

              This is question that I've thought long and hard about.


              The idea of coding to standards is appealing, but it is the wrong way to look at it. You should look at it as How is my decision helping me to deliver value to my client?. Case in point:


              JPA is a SUB-SET of Hibernate. Why would you choose to use something that gives you less? We had originally decided on using JPA and dropping into Hibernate as needed. Well in my case means learning two things brand new to me rather than one. It is a waste of my time and it is not helping the project.

              • 4. Re: To JPA or To Hibernate?
                nickarls

                Grant Rettke wrote on Feb 13, 2008 08:57 PM:


                JPA is a SUB-SET of Hibernate. Why would you choose to use something that gives you less? We had originally decided on using JPA and dropping into Hibernate as needed. Well in my case means learning two things brand new to me rather than one. It is a waste of my time and it is not helping the project.


                It is less only if you need more ;-)


                Ususally JPA will get you started (and quite far along the way). By the time you get to "what, is there no feature X in JPA?" you will probably be comfortable in moving to the superset...

                • 5. Re: To JPA or To Hibernate?
                  asookazian

                  Let's re-evaluate this question in light of EE 6 (and JPA 2.0 specifically with Criteria API from Hibernate added).


                  Also, you can't use MANUAL flushMode if Hibernate is not your persistence provider.  But using Hibernate directly and using Hibernate as a JPA persistence provider are two different things....

                  • 6. Re: To JPA or To Hibernate?

                    Grant Rettke wrote on Feb 13, 2008 20:57:


                    This is question that I've thought long and hard about.

                    The idea of coding to standards is appealing, but it is the wrong way to look at it. You should look at it as How is my decision helping me to deliver value to my client?. Case in point:

                    JPA is a SUB-SET of Hibernate. Why would you choose to use something that gives you less? We had originally decided on using JPA and dropping into Hibernate as needed. Well in my case means learning two things brand new to me rather than one. It is a waste of my time and it is not helping the project.


                    On the other hand, using Hibernate native API means your code locked in to compatibility with Hibernate, and you will not be able to migrate to another JPA provider as easily, I think your best course of action would be to evaluate both Hibernate and EclipseLink and decide by yourself which one implements the standard more precisely, which one has a more active community, which one has better documentation, more published books, etc, etc. (And which one has better vendor specific extensions)