Community
Participate
Working Groups
Support for derived identities - see section 2.4.1 of the JPA spec Here are the examples from the spec. The key thing that jumps out at me that is different from how we handle things now is the @ManyToOne being labeled as @Id. The parent entity has a simple primary key: @Entity public class Employee { @Id long empId; String name; ... } Case (a): The dependent entity uses IdClass to represent a composite key: public class DependentId { String name; // matches name of @Id attribute long emp; // matches name of @Id attribute and type of Employee PK } @Entity @IdClass(DependentId.class) public class Dependent { @Id String name; @Id @ManyToOne Employee emp; ... } Sample query: SELECT d FROM Dependent d WHERE d.name = 'Joe' AND d.emp.name = 'Sam' Case(b): The dependent entity uses EmbeddedId to represent a composite key: @Embeddable public class DependentId { String name; long empPK; // corresponds to PK type of Employee } @Entity public class Dependent { @EmbeddedId DependentId id; ... @MappedById("empPK") // maps to empPK attribute of embedded id @ManyToOne Employee emp; } Sample query: SELECT d FROM Dependent d WHERE d.id.name = 'Joe' AND d.emp.name = 'Sam'
241765 - EclipseLink support for derived identities is targeted for 2.0
I've looked into what it might take for us to support derived identities or at least tolerate them (not give invalid validation errors). One possibility for tolerance is to override the process of building specified mappings in AbstractJavaPersistentAttribute. So, a specified id mapping that also defaults to 1-1 in EclipseLink would now have a null specified mapping and a default 1-1. The user would see it as a default 1-1 mapping. We also would need to change the order of how we read annotations in EclipseLink, making sure to read OneToOne and ManyToOne before Id. We might need to change the validation for one-to-one and many-to-ones if they are derived identities (check the resource model for the Id annotation). We could potentially just disable validation in this case. I think that would cover us for just the tolerance use case.
This didn't quite make M1. All of the core refactoring and most of the model work is in place. Minor UI changes are required to complete this feature.
functionally complete and committed to head
Not sure this is working properly in 3.2.0M6. I'm seeing the error "The attribute matching the ID class attribute parent does not have the correct type long". Am I missing something?
Figured this one out. The problem was that I had: @Entity public class Parent { @Id Long id; } public class ChildPK implements Serializable { private long parent; private int someOtherParentId; } When ChildPK.parent is changed to "Long", it works. Either this is a case of the validations producing the wrong error message for a real problem, or there should be no error at all.
(In reply to comment #6) > Figured this one out. The problem was that I had: > > @Entity > public class Parent { > @Id Long id; > } > > public class ChildPK implements Serializable { > private long parent; > private int someOtherParentId; > } > > When ChildPK.parent is changed to "Long", it works. Either this is a case of > the validations producing the wrong error message for a real problem, or there > should be no error at all. Looks like we probably need to relax this validation to account for autoboxing. Please open a bug for this issue so we can track it separately from this enhancement. Thanks for bringing this to our attention. For M6, you could disable this error in our Errors/Warnings preferences as a workaround.
