OpenJPA
  1. OpenJPA
  2. OPENJPA-435

Change mapping defaults to assume foreign keys exist for relationships by default

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.9.0, 0.9.6, 0.9.7, 1.0.0, 1.0.1, 1.0.2, 1.1.0
    • Fix Version/s: 1.3.0
    • Component/s: sql
    • Labels:
      None

      Description

      OpenJPA's current defaults assume that no foreign keys exist. This leads to potentially more optimal SQL ordering, but often also leads to FK constraint violations when obvious FKs exist but are not declared. We should change this default to be more user-friendly, and add a note to our optimization guide as appropriate if there are actions users should take to optimize.

        Issue Links

          Activity

          Patrick Linskey created issue -
          Patrick Linskey made changes -
          Field Original Value New Value
          Link This issue is related to OPENJPA-431 [ OPENJPA-431 ]
          Patrick Linskey made changes -
          Comment [ I believe that this can be worked around in the short term by setting the MappingDefaults ForeignKeyDeleteAction and JoinForeignKeyDeleteAction properties to 'restrict':

          <property name="openjpa.MappingDefaults"
              value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/>

          Could someone who is seeing this behavior in their app give this a try and comment on this issue, please? ]
          Hide
          Patrick Linskey added a comment -

          I believe that this can be worked around in the short term by setting the MappingDefaults ForeignKeyDeleteAction and JoinForeignKeyDeleteAction properties to 'restrict':

          <property name="openjpa.jdbc.MappingDefaults"
          value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/>

          Could someone who is seeing this behavior in their app give this a try and comment on this issue, please?

          Of course, another workaround is to tell OpenJPA to look for foreign key constraints in the database. This can be quite slow, though. FTR, you can do this like so:

          <property name="openjpa.jdbc.SchemaFactory" value="native(ForeignKeys=true)"/>

          Show
          Patrick Linskey added a comment - I believe that this can be worked around in the short term by setting the MappingDefaults ForeignKeyDeleteAction and JoinForeignKeyDeleteAction properties to 'restrict': <property name="openjpa.jdbc.MappingDefaults" value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/> Could someone who is seeing this behavior in their app give this a try and comment on this issue, please? Of course, another workaround is to tell OpenJPA to look for foreign key constraints in the database. This can be quite slow, though. FTR, you can do this like so: <property name="openjpa.jdbc.SchemaFactory" value="native(ForeignKeys=true)"/>
          Hide
          Prashant Bhat added a comment -

          I'm using the first option for mapping tool and also during entityManagerFactory creation:
          <property name="openjpa.jdbc.MappingDefaults"
          value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/>

          And for me it's working perfectly with all constraints and I agree that changing the default behaviour to this makes it a lot easier for beginners(as I had the same issue and the manual was not very clear for me then! May be it's updated now)

          Regards,
          Prashant

          Show
          Prashant Bhat added a comment - I'm using the first option for mapping tool and also during entityManagerFactory creation: <property name="openjpa.jdbc.MappingDefaults" value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/> And for me it's working perfectly with all constraints and I agree that changing the default behaviour to this makes it a lot easier for beginners(as I had the same issue and the manual was not very clear for me then! May be it's updated now) Regards, Prashant
          Patrick Linskey made changes -
          Fix Version/s 1.2.0 [ 12313102 ]
          Fix Version/s 1.1.0 [ 12312344 ]
          Hide
          Michael Dick added a comment -

          Moving to next release

          Show
          Michael Dick added a comment - Moving to next release
          Michael Dick made changes -
          Fix Version/s 1.3.0 [ 12313326 ]
          Fix Version/s 1.2.0 [ 12313102 ]
          Hide
          Willis Blackburn added a comment -

          +1!

          It doesn't seem logical to assume that FKs don't exist.

          Reason #1: They usually do! Let's assume that people using OpenJPA are intelligent and are designing production-quality databases. Of course they're going to have FKs.

          Reason #2: The strategy of querying the database to discover the FKs seems at odds with the general JPA strategy of declaring the database metadata in code. We let the code define the database, not vice-versa.

          Reason #3: It leads to the fewest surprises. Consider:

          OpenJPA assumes FKs don't exist, and they don't: OK
          OpenJPA assumes FKs don't exist, and they do: FAIL!
          OpenJPA assumes FKs exist, and they don't: No worries!
          OpenJPA assumes FKs exist, and they do: OK

          Show
          Willis Blackburn added a comment - +1! It doesn't seem logical to assume that FKs don't exist. Reason #1: They usually do! Let's assume that people using OpenJPA are intelligent and are designing production-quality databases. Of course they're going to have FKs. Reason #2: The strategy of querying the database to discover the FKs seems at odds with the general JPA strategy of declaring the database metadata in code. We let the code define the database, not vice-versa. Reason #3: It leads to the fewest surprises. Consider: OpenJPA assumes FKs don't exist, and they don't: OK OpenJPA assumes FKs don't exist, and they do: FAIL! OpenJPA assumes FKs exist, and they don't: No worries! OpenJPA assumes FKs exist, and they do: OK

            People

            • Assignee:
              Unassigned
              Reporter:
              Patrick Linskey
            • Votes:
              2 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development