JPA Mini Book – First Steps and detailed concepts

Hello, how are you?

Today we will see about JPA: what is the persistence.xml file used for, how to create an entity, mapping easy and complex ids, creating relationships between the entities, automatically entity persistence and more.

Today we will see:

  • Page 02: Reasons that led to the creation of JPA
  • Page 03: What is JPA? What is a JPA Implementation?
  • Page 04: What is the persistence.xml file used for? And its configurations?
  • Page 05: Entity definitions. What are the Logic and Physical annotations?
  • Page 06: Id Generation: Definition, using Identity or Sequence
  • Page 07: Id Generation: TableGenerator and Auto
  • Page 08: Simple Composite Key
  • Page 09: Complex Composite Key
  • Page 10: How to get an EntityManager
  • Page 11: Mapping two or more tables in one entity
  • Page 12: Mapping Hierarchy: MappedSuperclass
  • Page 13: Mapping Hierarchy: Single Table
  • Page 14: Mapping Hierarchy: Joined
  • Page 15: Mapping Hierarchy: Table per Concrete Class
  • Page 16: Pros/Cons of each hierarchy mapping approach
  • Page 17: Embedded Objects
  • Page 18: ElementCollection – how to map a list of values into a class
  • Page 19: OneToOne unidirectional and bidirectional
  • Page 20: OneToMany/ManyToOne unidirectional and bidirectional
  • Page 21: ManyToMany unidirectional and bidirectional
  • Page 22: ManyToMany with extra fields
  • Page 23: How the Cascade functionality works? How should a developer use the OrphanRemoval? Handling the org.hibernate.TransientObjectException
  • Page 24: How to delete an entity with relationships. How to know which relationships are raising the exception
  • Page 25: Creating one EntityManagerFactory by application
  • Page 26: Understanding how the Lazy/Eager option works
  • Page 27: Handling the “cannot simultaneously fetch multiple bags” error

Just one more observation: I will not create a PDF file of this post. Just to create this material I already take several hours of code formatting, images production, translate all text to the English language and texts adjusts in this blog page. I am sorry, but there is no way to create a PDF file, maybe sometime later but I will not promise.

34 Thoughts on “JPA Mini Book – First Steps and detailed concepts

  1. Roberto Leon on April 25, 2013 at 10:30 am said:

    Hello, how can you do to persist this using JPQL? Thanks beforehand.

  2. Kapil Khanna on February 11, 2013 at 8:09 pm said:

    Yes and this is perfectly acceptable. You change behavior at deployment time w/o having to recompile code.
    However adding an interface to the codebase will require a recompile. See the difference?
    My point is it does not hurt to put in the interface. It costs nothing but makes your app scale up in a J2EE deployment. Even scaling vertically where the Views & Controller runs in one JVM (Servlets/JSP’s) and the Model (Entities) run in another JVM you will not be able to pass entities to the controller because they do not serialize.

    • uaihebert on February 11, 2013 at 8:18 pm said:

      1) If you think by OO, a class have no reason to know a Interface that it will not use it.
      2) A team with developers without experience will not know why the serializable is there (I saw that happing a lot of times), and will start adding it to several other classes thinking that it will solve some error.

      I sorry, but no, I do not see it as good practice. If it is not a requirement, it should not be present.

  3. Kapil Khanna on February 11, 2013 at 7:54 pm said:

    Java = WORA (Write Once Run Anywhere). Do not forget this basic premise :).

    • uaihebert on February 11, 2013 at 8:00 pm said:

      I do not forgot it, but sometimes an implementation does. =P

      Take the JPA implementation by example, you can have some methods behaving different in each implementation.

      Sometimes The spec says only what a method can or cannot do, allowing it to behave and to have an final destination chosen by it own.

      Thanks for passing by.

  4. Kapil Khanna on February 7, 2013 at 8:03 pm said:

    Couple of points of interest here :

    1. Usually have the owner of the ManyToMany relationship be the entity that has the less rows when navigating the right side of the join.
    So for e.g. If 1 student can have many courses and many students can have one course we have a many to many relationship between students and courses. In such a model (practically), when navigating from a student record to courses you will have fewer records than from navigating courses to student. In such a case, it makes more sense to define the owner of the relationship be student and not courses. The reason I am saying this when you have a new student in the system its more optimal from a SQL standpoint to navigate from Student to Courses and add the new course. If you had to navigate the other way you will potentially have many more records which means more objects loaded to represent the relationship which means a poorer performing application.

    2. Also in your example you do not need to set both of these
    person.setDog(dogs);
    dog.setPersons(persons);

    just person.setDog(dogs) should work.

    • uaihebert on February 11, 2013 at 7:49 pm said:

      Hello Kapil,

      1. Sometimes you do not know which entity will have less rows, that I think that the books that I read do not put who should be the owner like you did. But I did like your point of view.

      2. To work like that depends on your implementation. The JPA Pro 2 book makes it clear that passing to only one side the reference the other side will see it.

      Thanks for passing by.

      PS.: Sorry for taking too long to answer you.

  5. Kapil Khanna on February 7, 2013 at 10:48 am said:

    I outlined the reason why you would implement the interface in my previous comment.
    I can try and explain once again.
    As an example let’s say you are building a Human Resources application that you intend to sell to clients. You are using JPA and do not implement the Serializable interface. One of the clients you sell to is a very large corporation that has a clustered environment. When they buy your application and try to deploy it on their environment it will start throwing serialization errors.
    Does that make sense?

    • uaihebert on February 11, 2013 at 7:47 pm said:

      Hello Kapil,

      I do not know what is reality of software programming where you live, but I know several developers that never built a software to be sold.

      A developer must understand this: If your software is to be used in a non clustered environment, you will not need to add the interface. If your software is for a clustered environment the interface is not a good practice, but a requirement. That is the difference.

      And if you are building a software to be sold, only by applying the interface will not make your software ready for a clustered environment. A clustered environment is a Requirement that should be specified in the beginning.

      I do respect your opinion, but I do not agree with it. [=

      Thanks for passing by.

  6. Kapil Khanna on February 5, 2013 at 12:33 am said:

    Thanks for taking the time to write out this tutorial.

    A few suggestions to improve this article.
    - Firstly its a good practice to make sure all entity classes implement the java.io.Serializable interface.

    - When setting the @OneToMany annotation, it is important to talk about the CascadeType options for easier creation/updation of entities. An example of code for insert/update/delete of the entities with and without the CascadeType option will demonstrate the difference in use.

    - The mappedBy value in the cellular class = cellular. What this defines should be explained. This actually refers to the instance variable cellular on the Call object. Since the names are all kept the same most readers will be confused on the name mapping. They may think it refers to the classname when in fact it has nothing to do with the class name.
    I find it useful to actually change the names to demonstrate the actual relationships. So calling cellular, cellularRef on the Call object would make this point more obvious.

    • uaihebert on February 5, 2013 at 8:23 pm said:

      Hello Kapil,

      1) I just see implementing java.io.Serializable as good practice if you have a multi clustered environment or remove EJB (or anything related to serialization). Do you have any article that talk about that always implementing java.io.Serializable is a good practive?
      2) In this article there is a page that talks about Cascade. [=
      3) Thanks for the mappedBy tip. I will edit it later. [=

      Thanks for passing by! =D

      • Kapil Khanna on February 5, 2013 at 8:38 pm said:

        When you write code you do not know the target configuration for deployment especially for packaged apps. If you do not implement Serializable and ship your bundle off to a client and they are running a multi clustered environment, guess what will happen?

        • uaihebert on February 6, 2013 at 12:51 pm said:

          Hello Kapil,

          I do know some seniors Java developers that use JPA and never needed to work with clustered environments.

          Thinking about OO, if a class will never be used in an clustered environment why would it be considered a good practice to add this Interface?

          You thoughts will remain here to be used as an alert to other developers.

          Thanks for passing by! [=

          • Kapil Khanna on February 11, 2013 at 8:31 pm said:

            Well its good to have differences in opinion :).

            When I write software I can never tell if it is going to be used in a clustered environment or not. All the enterprises i have worked for have had nothing but multi clustered (Cluster of clusters) environments. I rarely write software that would work only on a single node. Unless of course its a quick Proof Of concept.

            • uaihebert on February 19, 2013 at 1:53 pm said:

              Indeed.

              I always will have the idea that a code that does not follow a good practice will run in every environment.

              In your case, is not good practice but a requirement. Where I live I know a lot of developers that never worked with clustered environment.

              Thanks for passing by.

  7. Edenir on January 8, 2013 at 8:45 pm said:

    Excelente material Hebert, parabéns pelo trabalho!

Comment navigation

 

Leave a Reply

Post Navigation