OpenJPA
  1. OpenJPA
  2. OPENJPA-1720

MappingTool does not add version column for subclass

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      MappingTool does not add version column for subclass

      1. OPENJPA-1720.patch
        2 kB
        Fay Wang
      2. jpa_test.zip
        6 kB
        Howard

        Activity

        Hide
        Howard added a comment -

        Reproduce case

        Ant target "sql" creates SQL scripts.

        The output
        CREATE TABLE Child (m_id INTEGER NOT NULL, m_val INTEGER, PRIMARY KEY (m_id));
        should be
        CREATE TABLE Child (m_id INTEGER NOT NULL, m_val INTEGER, m_ver INTEGER, PRIMARY KEY (m_id));

        Show
        Howard added a comment - Reproduce case Ant target "sql" creates SQL scripts. The output CREATE TABLE Child (m_id INTEGER NOT NULL, m_val INTEGER, PRIMARY KEY (m_id)); should be CREATE TABLE Child (m_id INTEGER NOT NULL, m_val INTEGER, m_ver INTEGER, PRIMARY KEY (m_id));
        Hide
        Howard added a comment -

        Summary of jpa_test.zip reproduce case

        // MappingTool schemaAction build is ok; m_ver column is generated
        @Entity
        public class Flat

        { @Version private int m_ver; @Id private int m_id; }

        @Entity
        @Inheritance(strategy=InheritanceType.JOINED)
        public abstract class Parent

        { @Id private int m_id; }

        // MappingTool schemaAction build is bad; m_ver column is not generated
        @Entity
        public class Child extends Parent

        { @Version private int m_ver; private int m_val; }
        Show
        Howard added a comment - Summary of jpa_test.zip reproduce case // MappingTool schemaAction build is ok; m_ver column is generated @Entity public class Flat { @Version private int m_ver; @Id private int m_id; } @Entity @Inheritance(strategy=InheritanceType.JOINED) public abstract class Parent { @Id private int m_id; } // MappingTool schemaAction build is bad; m_ver column is not generated @Entity public class Child extends Parent { @Version private int m_ver; private int m_val; }
        Hide
        Howard added a comment -

        I also noticed that the @Version field is not updated when persisting updates to Child.
        Will the bug fix address this as well?
        Or is this a different bug?

        Show
        Howard added a comment - I also noticed that the @Version field is not updated when persisting updates to Child. Will the bug fix address this as well? Or is this a different bug?
        Hide
        Fay Wang added a comment -

        Hi Howard,
        OpenJPA seems inconsistent in handling the version field when inheritance is involved. In some situations, the following error message is thrown from ColumnVersionStrategy:

        not-base-vers: Type "

        {0}

        " specifies a version strategy, but has a mapped \
        persistence capable superclass or is embedded. Subclasses and embedded \
        values must use the version strategy of the base or embedding class.

        In other situations (the one reported in this JIRA and org.apache.openjpa.persistence.inheritance.TestDefaultInheritanceStrategy), this error condition is not detected. These test cases have one thing in common: the parent class does not have version field, while the child class has. In this scenarios, the version column is not created in the child table nor in the parent table, and the version field is totally ignored by the OpenJPA. The attached patch attempts to detect the error condition and issues the error message if the condition is found true. However, this breaks the test case (mentioned above) of the OpenJPA regression bucket and may potentially break existing applications. Adding independent version support for child only, on the other hand, will have bigger impact and is not compatible with the current OpenJPA version handling.
        Weighing the pros and cons, the better approach to this problem seems to move the version field from the child to the parent to gain full version support from OpenJPA. Please let me know what you think.

        Show
        Fay Wang added a comment - Hi Howard, OpenJPA seems inconsistent in handling the version field when inheritance is involved. In some situations, the following error message is thrown from ColumnVersionStrategy: not-base-vers: Type " {0} " specifies a version strategy, but has a mapped \ persistence capable superclass or is embedded. Subclasses and embedded \ values must use the version strategy of the base or embedding class. In other situations (the one reported in this JIRA and org.apache.openjpa.persistence.inheritance.TestDefaultInheritanceStrategy), this error condition is not detected. These test cases have one thing in common: the parent class does not have version field, while the child class has. In this scenarios, the version column is not created in the child table nor in the parent table, and the version field is totally ignored by the OpenJPA. The attached patch attempts to detect the error condition and issues the error message if the condition is found true. However, this breaks the test case (mentioned above) of the OpenJPA regression bucket and may potentially break existing applications. Adding independent version support for child only, on the other hand, will have bigger impact and is not compatible with the current OpenJPA version handling. Weighing the pros and cons, the better approach to this problem seems to move the version field from the child to the parent to gain full version support from OpenJPA. Please let me know what you think.
        Hide
        Howard added a comment -

        I will use your suggested workaround (put version field in parent instead child). However, this doubles the number of UPDATE queries whenever child field changes are persisted ... one UPDATE on the parent version field + one UPDATE on the "dirty" child fields. Can this no-version-field-in-child bug be fixed so I can avoid this extra overhead?

        Show
        Howard added a comment - I will use your suggested workaround (put version field in parent instead child). However, this doubles the number of UPDATE queries whenever child field changes are persisted ... one UPDATE on the parent version field + one UPDATE on the "dirty" child fields. Can this no-version-field-in-child bug be fixed so I can avoid this extra overhead?
        Hide
        Fay Wang added a comment -

        Hi Howard,
        With Joined table strategy, any update in Child will involve two update because the version column is in the parent table, and the child field is in the Child table. This is working as design. If you want to avoid the extra overhead, you can use SINGLE Table strategy.

        Show
        Fay Wang added a comment - Hi Howard, With Joined table strategy, any update in Child will involve two update because the version column is in the parent table, and the child field is in the Child table. This is working as design. If you want to avoid the extra overhead, you can use SINGLE Table strategy.

          People

          • Assignee:
            Fay Wang
            Reporter:
            Howard
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development