Package ejava.examples.orm.rel

Class OneToOneTest

  • public class OneToOneTest
extends DemoBase
    This test case provides a demo of using a class that has been mapped to the database with only basic class annotations. All defaults will be determined by the Java Persistence provider.

    • Field Detail

      • PHOTO_FILE

        private static final String PHOTO_FILE

      • image

        private byte[] image

    • Constructor Detail

      • OneToOneTest

        public OneToOneTest()

    • Method Detail

      • testUni

        public void testUni()
        This test provides an example of setting a OneToOne relationship between two independent objects in the database. The Person is initially created with a FK=null and then its setter is later called to setup the relationship between Person and Photo.

      • testCacadePersist

        public void testCacadePersist()
        This test provides an example of persisting an object tree from the owning side. The tree is very small, consisting of only the Person and Photo, but demonstrates the Cascade.PERSIST capability.

      • testPersistOnSetter

        public void testPersistOnSetter()
        This test demonstrates an issue I found with inserting objects on the inverse side of a relationship during the owner's setter(). If the object uses generated values, the id within the Photo object is not being updated. Once can't merge or refresh the photo until a separate set of objects are created using the find.

      • testPrimaryKeyJoin

        public void testPrimaryKeyJoin()
        This demonstrates a OneToOne uni-directional relationship between the Borrower and Person where they are being joined by primary key instead of a separate column in the borrower table.

      • testOneToOneBiDirectional

        public void testOneToOneBiDirectional()
        This demonstrates a OneToOne bi-directional relationship between two logically independent object; Applicant and Borrower. Ignore the fact they they both have a relationship to a Person. Focus on the fact that they can both independently exist and that the Applicant physically owns the relationship by hosting the foreign key field.