OpenJPA
  1. OpenJPA
  2. OPENJPA-2335

Constrained foreign key column value setting needs to be flexible

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.0
    • Component/s: None
    • Labels:
      None

      Description

      Should allow setting a column from default value to a non-default value. The logic had a bug.

        Issue Links

          Activity

          Pinaki Poddar created issue -
          Hide
          ASF subversion and git services added a comment -

          Commit 1447906 from Pinaki Poddar
          [ https://svn.apache.org/r1447906 ]

          OPENJPA-2335: Set non-default value to a foreign key contrained column

          Show
          ASF subversion and git services added a comment - Commit 1447906 from Pinaki Poddar [ https://svn.apache.org/r1447906 ] OPENJPA-2335 : Set non-default value to a foreign key contrained column
          Pinaki Poddar made changes -
          Field Original Value New Value
          Fix Version/s 2.3.0 [ 12319463 ]
          Pinaki Poddar made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Mark Struberg added a comment -

          The change seems broken, it makes a few of my apps blow up.

          I do not really get the whole change. The bug description doesn't tell me why this change got done and there is also no unit test for this change to tell me what you did like to fix.

          I can give you my use case which is now broken

          Car -> n Inspections
          with @OrderColumn(name = "POSITION")

          Car c = new Car();
          Inspection i1 = new Inspection(1, c); //Inspection adds itself to car.inspections
          Inspection i2 = new Inspection(2, c);
          em.persist(c).

          This currently blurps out with

          Caused by: <openjpa-2.3.0-r422266:1538090M fatal user error> org.apache.openjpa.persistence.InvalidStateException: Attempt to set column "Inspection.POSITION" to two different values: (class java.lang.Integer)"1", (class java.lang.Integer)"0" This can occur when you fail to set both sides of a two-sided relation between objects, or when you map different fields to the same column, but you do not keep the values of these fields in synch.
          at org.apache.openjpa.jdbc.sql.PrimaryRow.setObject(PrimaryRow.java:344)
          at org.apache.openjpa.jdbc.sql.RowImpl.setInt(RowImpl.java:442)
          at org.apache.openjpa.jdbc.meta.strats.PrimitiveFieldStrategy.update(PrimitiveFieldStrategy.java:164)
          at org.apache.openjpa.jdbc.meta.strats.PrimitiveFieldStrategy.insert(PrimitiveFieldStrategy.java:124)
          at org.apache.openjpa.jdbc.meta.FieldMapping.insert(FieldMapping.java:623)
          at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.insert(AbstractUpdateManager.java:238)
          at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.populateRowManager(AbstractUpdateManager.java:165)
          at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:96)
          at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:77)

          It seems that the @OrderColumn is the issue in this case. Your change looks fine for primary keys, but OrderColumns and all other stuff which gets auto-managed by OpenJPA also use the same code.

          Maybe we should only do these checks in case of real primary or foreign keys?

          Show
          Mark Struberg added a comment - The change seems broken, it makes a few of my apps blow up. I do not really get the whole change. The bug description doesn't tell me why this change got done and there is also no unit test for this change to tell me what you did like to fix. I can give you my use case which is now broken Car -> n Inspections with @OrderColumn(name = "POSITION") Car c = new Car(); Inspection i1 = new Inspection(1, c); //Inspection adds itself to car.inspections Inspection i2 = new Inspection(2, c); em.persist(c). This currently blurps out with Caused by: <openjpa-2.3.0-r422266:1538090M fatal user error> org.apache.openjpa.persistence.InvalidStateException: Attempt to set column "Inspection.POSITION" to two different values: (class java.lang.Integer)"1", (class java.lang.Integer)"0" This can occur when you fail to set both sides of a two-sided relation between objects, or when you map different fields to the same column, but you do not keep the values of these fields in synch. at org.apache.openjpa.jdbc.sql.PrimaryRow.setObject(PrimaryRow.java:344) at org.apache.openjpa.jdbc.sql.RowImpl.setInt(RowImpl.java:442) at org.apache.openjpa.jdbc.meta.strats.PrimitiveFieldStrategy.update(PrimitiveFieldStrategy.java:164) at org.apache.openjpa.jdbc.meta.strats.PrimitiveFieldStrategy.insert(PrimitiveFieldStrategy.java:124) at org.apache.openjpa.jdbc.meta.FieldMapping.insert(FieldMapping.java:623) at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.insert(AbstractUpdateManager.java:238) at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.populateRowManager(AbstractUpdateManager.java:165) at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:96) at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:77) It seems that the @OrderColumn is the issue in this case. Your change looks fine for primary keys, but OrderColumns and all other stuff which gets auto-managed by OpenJPA also use the same code. Maybe we should only do these checks in case of real primary or foreign keys?
          Mark Struberg made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Assignee Pinaki Poddar [ ppoddar@apache.org ]
          Mark Struberg made changes -
          Priority Major [ 3 ] Blocker [ 1 ]
          Hide
          ASF subversion and git services added a comment -

          Commit 1538463 from Mark Struberg
          [ https://svn.apache.org/r1538463 ]

          rollback of openjpa 2.3.0 release

          We first need to fix OPENJPA-2335 before we can continue

          Show
          ASF subversion and git services added a comment - Commit 1538463 from Mark Struberg [ https://svn.apache.org/r1538463 ] rollback of openjpa 2.3.0 release We first need to fix OPENJPA-2335 before we can continue
          Hide
          ASF subversion and git services added a comment -

          Commit 1538480 from Mark Struberg in branch 'openjpa/branches/2.3.x'
          [ https://svn.apache.org/r1538480 ]

          OPENJPA-2335 add a unit test for demonstrating the bug

          Show
          ASF subversion and git services added a comment - Commit 1538480 from Mark Struberg in branch 'openjpa/branches/2.3.x' [ https://svn.apache.org/r1538480 ] OPENJPA-2335 add a unit test for demonstrating the bug
          Hide
          Mark Struberg added a comment -

          The issue happens if an @OrderColumn on the @OneToMany side references a (read-only) attribute in the entity. I'm not really sure if this is allowed by the spec though:
          " The order column is not visible as part of the state of the entity or embeddable class."

          It used to work without problems in openjpa-2.2.2 though.

          This also seems to work fine in hibernate
          http://stackoverflow.com/questions/2956171/jpa-2-0-ordercolumn-annotation-in-hibernate-3-5

          Show
          Mark Struberg added a comment - The issue happens if an @OrderColumn on the @OneToMany side references a (read-only) attribute in the entity. I'm not really sure if this is allowed by the spec though: " The order column is not visible as part of the state of the entity or embeddable class." It used to work without problems in openjpa-2.2.2 though. This also seems to work fine in hibernate http://stackoverflow.com/questions/2956171/jpa-2-0-ordercolumn-annotation-in-hibernate-3-5
          Hide
          ASF subversion and git services added a comment -

          Commit 1540277 from Mark Struberg in branch 'openjpa/branches/2.3.x'
          [ https://svn.apache.org/r1540277 ]

          OPENJPA-2335 only handle key columns very restrictive

          There is no reason to forbid updates to other Columns like OrderColumn, etc

          Show
          ASF subversion and git services added a comment - Commit 1540277 from Mark Struberg in branch 'openjpa/branches/2.3.x' [ https://svn.apache.org/r1540277 ] OPENJPA-2335 only handle key columns very restrictive There is no reason to forbid updates to other Columns like OrderColumn, etc
          Hide
          ASF subversion and git services added a comment -

          Commit 1540371 from Mark Struberg in branch 'openjpa/branches/2.3.x'
          [ https://svn.apache.org/r1540371 ]

          OPENJPA-2335 review test case and update checks

          Show
          ASF subversion and git services added a comment - Commit 1540371 from Mark Struberg in branch 'openjpa/branches/2.3.x' [ https://svn.apache.org/r1540371 ] OPENJPA-2335 review test case and update checks
          Mark Struberg made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Romain Manni-Bucau made changes -
          Link This issue is duplicated by OPENJPA-2573 [ OPENJPA-2573 ]
          Hide
          ASF subversion and git services added a comment -

          Commit 1667136 from Mark Struberg in branch 'openjpa/trunk'
          [ https://svn.apache.org/r1667136 ]

          OPENJPA-2335 only handle key columns very restrictive

          There is no reason to forbid updates to other Columns like OrderColumn, etc
          Ported over from 2.3.x

          Show
          ASF subversion and git services added a comment - Commit 1667136 from Mark Struberg in branch 'openjpa/trunk' [ https://svn.apache.org/r1667136 ] OPENJPA-2335 only handle key columns very restrictive There is no reason to forbid updates to other Columns like OrderColumn, etc Ported over from 2.3.x

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development