glassfish
  1. glassfish
  2. GLASSFISH-597

JoinColumns is mandatory for using composite FK

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 9.0pe
    • Fix Version/s: 4.0_b60
    • Component/s: entity-persistence
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      597

      Description

      It appears to me that TopLink Essential requires JoinColumns to be set when
      there is a composite FK. I don't see this being mentioned in the spec. Can the
      default join column names not be calculated for such a case? In the attached
      test case, the entities are defined like this:

      @Entity
      @IdClass(EventPK.class)
      public class Event implements java.io.Serializable {

      @Id String notificationId;

      @Id String discriminatorValue = this.getClass().getSimpleName();
      }

      @Entity
      @IdClass(EventPK.class)
      public class Alarm implements java.io.Serializable {

      @Id String notificationId;

      @Id String discriminatorValue = this.getClass().getSimpleName();

      @OneToOne Event event;

      }

      When I run this, I get the exception:
      Exception Description: The @JoinColumns on the annotated element [Event
      Alarm.event] from the entity class [class Alarm] is incomplete. When the source
      entity class uses a composite primary key, a @JoinColumn must be specified for
      each join column using the @JoinColumns. Both the name and the
      referenceColumnName elements must be specified in each such @JoinColumn.

      The same exception appears even when I run verifier.

        Activity

        Hide
        gyorke added a comment -

        Sahoo,
        The reason you considered GLASSFISH-555 a bug is the same reason this issue is
        not a bug. TopLink can always default a OneToOne relationship. TopLink can
        always default a ToMany relationship where generic collections are used and
        GLASSFISH-555 was filed because we chose to do that defaulting. In the case of
        @JoinColumns (composite FKs) the provider can only default the @JoinColumn
        annotation in its entirety. If a user specifies a partial @JoinColumn, no
        referencedColumnName, then the provider can not determine which target column
        the custom FK name should reference and what other FK names should be defaulted
        and mapped to. The provider can not always calculate defaults for composite FKs.
        However, whether the provider can calculate the @JoinColumns or not is a
        non-issue. Sections 2.1.8 and 9.1.6 do not contradict each other they
        compliment each other. 2.1.8 talks about defaulting a non-composite FK and 9.1.6
        talks about how to specify a composite FK making this issue “not a bug�.
        TopLink has always highly valued the user experience and I believe that in
        the cases where we can calculate @JoinColumns we should. So this issue should
        be an enhancement request and GLASSFISH-555 should be marked "invalid"
        --Gordon

        Show
        gyorke added a comment - Sahoo, The reason you considered GLASSFISH-555 a bug is the same reason this issue is not a bug. TopLink can always default a OneToOne relationship. TopLink can always default a ToMany relationship where generic collections are used and GLASSFISH-555 was filed because we chose to do that defaulting. In the case of @JoinColumns (composite FKs) the provider can only default the @JoinColumn annotation in its entirety. If a user specifies a partial @JoinColumn, no referencedColumnName, then the provider can not determine which target column the custom FK name should reference and what other FK names should be defaulted and mapped to. The provider can not always calculate defaults for composite FKs. However, whether the provider can calculate the @JoinColumns or not is a non-issue. Sections 2.1.8 and 9.1.6 do not contradict each other they compliment each other. 2.1.8 talks about defaulting a non-composite FK and 9.1.6 talks about how to specify a composite FK making this issue “not a bug�. TopLink has always highly valued the user experience and I believe that in the cases where we can calculate @JoinColumns we should. So this issue should be an enhancement request and GLASSFISH-555 should be marked "invalid" --Gordon
        Hide
        Sanjeeb Sahoo added a comment -

        Gordon,

        How can TopLink safely decide whether a relationship is bidirectional? How can
        TopLink decide whether a relationship is ManyToMany?

        I understand the need to disallow a partial JoinColumns. But when user has not
        placed JoinColumns at all, why can't provider calculate the default value? I
        like to read the spec in black and white. Where does the spec says that 2.1.8 is
        only applicable for non-composite FK.

        Sahoo

        Show
        Sanjeeb Sahoo added a comment - Gordon, How can TopLink safely decide whether a relationship is bidirectional? How can TopLink decide whether a relationship is ManyToMany? I understand the need to disallow a partial JoinColumns. But when user has not placed JoinColumns at all, why can't provider calculate the default value? I like to read the spec in black and white. Where does the spec says that 2.1.8 is only applicable for non-composite FK. Sahoo
        Hide
        gyorke added a comment -

        Sahoo,
        For GLASSFISH-555 TopLink does not need to 'decide' on the nature of a
        relationship. TopLink simply defaults undefined relationships as
        uni-directional mappings either OneToMany or OneToOne.
        As for this bug I do not believe we are in disagreement on if TopLink can
        calculate @JoinColumns in certain circumstances only on the nature of this bug
        report.
        If you are reading the spec in "black and white" where does it mention
        composite FKs or multiple join columns(other than the JoinTable reference) in
        section 2.1.8?
        --Gordon

        Show
        gyorke added a comment - Sahoo, For GLASSFISH-555 TopLink does not need to 'decide' on the nature of a relationship. TopLink simply defaults undefined relationships as uni-directional mappings either OneToMany or OneToOne. As for this bug I do not believe we are in disagreement on if TopLink can calculate @JoinColumns in certain circumstances only on the nature of this bug report. If you are reading the spec in "black and white" where does it mention composite FKs or multiple join columns(other than the JoinTable reference) in section 2.1.8? --Gordon
        Hide
        Sanjeeb Sahoo added a comment -

        Section #2.1.8 says the following:
        "This section defines the mapping defaults that apply to the use of the
        OneToOne, OneToMany,ManyToOne, and ManyToMany relationship modeling annotations."

        Where does it say that it is only applicable for entities with simple PK?

        Sahoo

        Show
        Sanjeeb Sahoo added a comment - Section #2.1.8 says the following: "This section defines the mapping defaults that apply to the use of the OneToOne, OneToMany,ManyToOne, and ManyToMany relationship modeling annotations." Where does it say that it is only applicable for entities with simple PK? Sahoo
        Hide
        Mitesh Meswani added a comment -

        Marking as fixed. As per Peter, in EclipseLink, the following example will now work without specifying a JoinColumn:

        
        @Entity
        
        @IdClass(EmpPK.class)
        public class Employee implements java.io.Serializable {
        
        @Id String Id1;
        
        @Id String id2;
        }
        
        @Entity
        public class Address implements java.io.Serializable {
        ...
        ...
        @OneToOne Employee employee;
        
        }
        
        
        Show
        Mitesh Meswani added a comment - Marking as fixed. As per Peter, in EclipseLink, the following example will now work without specifying a JoinColumn: @Entity @IdClass(EmpPK.class) public class Employee implements java.io.Serializable { @Id String Id1; @Id String id2; } @Entity public class Address implements java.io.Serializable { ... ... @OneToOne Employee employee; }

          People

          • Assignee:
            tware
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: