<< Back to previous view

[JPA_SPEC-39] Clarify requirements on polymorphic associations Created: 21/Sep/12  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: w_c_smith Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: ldemichiel and w_c_smith

 Description   

The 2.0 specification states in 2.9 that "Relationships are polymorphic", but there exists one case that appears to be completely valid JPA that Hibernate explicitly does not support. The specification should explicitly state whether a provider is required to support this case.

When using a joined or single-table inheritance strategy, it is a common occurrence that an entity (e.g., Order) has a ManyToOne relationship with another entity (e.g., Customer). Since JPA supports class inheritance, it is possible that some of the Order instances are actually instances of a subclass (SpecialOrder), and we might want to have a Collection of just the SpecialOrder s on the Customer entity. (This is especially likely if Order is abstract and we want relationships directly to the subclasses.) An example class hierarchy looks like this:

@Entity
public class Customer {
  @OneToMany(mappedBy = "customer")
  private Set<SpecialOrder> specialOrders;

  @OneToMany(mappedBy = "customer")
  private Set<RegularOrder> regularOrders;
}

@Entity
public abstract class AbstractOrder {
  @ManyToOne
  private Customer customer;
}

@Entity
public class SpecialOrder extends AbstractOrder {
  private Date shippingDate;
}

@Entity
public class RegularOrder extends AbstractOrder {
  private Integer storeNumber;
}

The specification appears to imply but does not explicitly state that this arrangement is valid, while Hibernate explicitly requires that the mappedBy property be physically present on the exact class specified in the relationship mapping, not inherited from a superclass. This mismatch has inspired a surprising number of "how-to-work-around" blog posts and should be explicitly resolved for the next version of the specification.


Generated at Sat Apr 19 05:37:25 UTC 2014 using JIRA 4.0.2#472.