OpenJPA
  1. OpenJPA
  2. OPENJPA-677

Single Table Inheritance Strategy causes entity identity issues

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.3.0
    • Fix Version/s: 1.2.3, 1.3.0, 2.0.0-M1
    • Component/s: None
    • Labels:
      None
    • Environment:
      IBM Java 1.5

      Description

      Entity objects that are pulled out from the database using bean methods (get*()) are not the same objects that are pulled out using using other methods(find(), getReference()).

      This occurs only when using Single Table Inheritance.

      This works on 0.9.7, in other versions Exception is thrown (https://issues.apache.org/jira/browse/OPENJPA-494) , in latest version from trunk test fails.

        Activity

        Hide
        Przemek Koprowski added a comment -

        In order to run tests:
        1. Add OpenJPA libraries to the build path.
        2. Change the path in the build.properties file.
        3. Run the enchanceWorkspaceAndDeleteDB task from build.xml.

        Show
        Przemek Koprowski added a comment - In order to run tests: 1. Add OpenJPA libraries to the build path. 2. Change the path in the build.properties file. 3. Run the enchanceWorkspaceAndDeleteDB task from build.xml.
        Hide
        Pinaki Poddar added a comment -

        The bug is reproducible.

        The workaround is to change RegularUsr.admin field from lazily loaded to eagerly loaded.

        The bug seems to be how OpenJPA determines the concrete type of a relation from the record row data and the discrimnator column. In this case
        mysql> select * from computeruser;
        ---------------------------------------

        oid DTYPE ADMIN_OID
        ---------------------------------------
        101 admin NULL
        102 user 101
        ---------------------------------------

        During load of row 102, i.e. '102 'user' 101', OpenJPA tries to store a FK (pointing to Admin) for the row 102 (which represents a RegularUser).
        However, because the row's discrimnator value is 'user', OpenJPA wrongly assumes that 101 is identifier for RegularUser and that is the oid is store intermediately in RegularUser-102's admin field.

        Later when OpenJPA reads the full row 101, (say for find()) it does construct a Admin-102 instance but that other identifier has created a different Admin object and hence the error.

        Eager loading gets rid of the problem because then both the rows are read in a single query and the ambiguity of discriminator value does not arise.

        Show
        Pinaki Poddar added a comment - The bug is reproducible. The workaround is to change RegularUsr.admin field from lazily loaded to eagerly loaded. The bug seems to be how OpenJPA determines the concrete type of a relation from the record row data and the discrimnator column. In this case mysql> select * from computeruser; --------------------------------------- oid DTYPE ADMIN_OID --------------------------------------- 101 admin NULL 102 user 101 --------------------------------------- During load of row 102, i.e. '102 'user' 101', OpenJPA tries to store a FK (pointing to Admin) for the row 102 (which represents a RegularUser). However, because the row's discrimnator value is 'user', OpenJPA wrongly assumes that 101 is identifier for RegularUser and that is the oid is store intermediately in RegularUser-102's admin field. Later when OpenJPA reads the full row 101, (say for find()) it does construct a Admin-102 instance but that other identifier has created a different Admin object and hence the error. Eager loading gets rid of the problem because then both the rows are read in a single query and the ambiguity of discriminator value does not arise.
        Hide
        Pinaki Poddar added a comment -

        This is an intermediate (and inaccurate) fix for the problem.
        This will only work when the most-derived class is target of a relation.
        For example, declared type of RegularUser.admin is Admin which is the most-derived class in this case and hence only the fix works. Otherwise, most likely it will show the same error.

        Will attempt to put a more comprehensive fix

        Show
        Pinaki Poddar added a comment - This is an intermediate (and inaccurate) fix for the problem. This will only work when the most-derived class is target of a relation. For example, declared type of RegularUser.admin is Admin which is the most-derived class in this case and hence only the fix works. Otherwise, most likely it will show the same error. Will attempt to put a more comprehensive fix
        Hide
        Pinaki Poddar added a comment -

        The later fix is more general. Please confirm if this fix resolves the reported issue or not.

        Show
        Pinaki Poddar added a comment - The later fix is more general. Please confirm if this fix resolves the reported issue or not.
        Hide
        Przemek Koprowski added a comment -

        Thank you.

        Show
        Przemek Koprowski added a comment - Thank you.
        Hide
        Michael Dick added a comment -

        Trunk was 1.3.0-SNAPSHOT when this was committed.

        Show
        Michael Dick added a comment - Trunk was 1.3.0-SNAPSHOT when this was committed.
        Hide
        Michael Dick added a comment -

        Closing issues which have code changes and have not been modified for a while.

        If there is more work to be done for this issue please check whether it has already been included in an OpenJPA release.

        If the changes are in an OpenJPA release please open a new issue and link to this one.

        If the changes are not in an OpenJPA release you may reopen this issue or create a new issue.

        Show
        Michael Dick added a comment - Closing issues which have code changes and have not been modified for a while. If there is more work to be done for this issue please check whether it has already been included in an OpenJPA release. If the changes are in an OpenJPA release please open a new issue and link to this one. If the changes are not in an OpenJPA release you may reopen this issue or create a new issue.

          People

          • Assignee:
            Pinaki Poddar
            Reporter:
            Przemek Koprowski
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development