JPA 2 Hibernate mapping with composite key in primary key using @IdClass with 3 tier structure

Question

This question is very similar to: JPA (Hibernate, EclipseLink) mapping: why doesn't this code work (chain of 2 relationships using JPA 2.0, @EmbeddedId composite PK-FK)?

Actually my only (from meaningful that I spotted) difference is that I use @IdClass and that I most probably won't be able to switch to a different provider than hibernate.

but anyway here is the code (removed parts that where unimportant):

PermissionContextType.java:

@Entity
@IdClass(PermissionContextTypePk.class)
public class PermissionContextType{
   @Id    
   private String id;    

   @Id
   @JoinColumn (name = "PROJECT", referencedColumnName = "ID")
   @ManyToOne ()
   private Project project;

   public static class PermissionContextTypePk implements Serializable{
       public String project;
       public String id;
       // ... eq and hashCode here ...
   }

}

PermissionContext.java:

@Entity
@IdClass(PermissionContextPk.class)
public class PermissionContext{
   @Id
   private String id;

   @Id
   @JoinColumns ({
            @JoinColumn (name = "PROJECT", referencedColumnName = "PROJECT"),
            @JoinColumn (name = "PERMISSIONCONTEXTTYPE", referencedColumnName = "ID")
        })
   @ManyToOne
   private PermissionContextType permissionContextType;

   public static class PermissionContextPk implements Serializable{
      public String id;
      public PermissionContextTypePk permissionContextType;
      // ... eq and hashCode here ...
   }
}

Permission.java:

@Entity
@IdClass(PermissionPk.class)
public class Permission{

   @Id
   private String id;

   @Id
   @JoinColumns ({
            @JoinColumn (name = "PROJECT", referencedColumnName = "PROJECT"),
            @JoinColumn (name = "PERMISSIONCONTEXTTYPE", referencedColumnName = "PERMISSIONCONTEXTTYPE"),
            @JoinColumn (name = "PERMISSIONCONTEXT", referencedColumnName = "ID")
        })
   @ManyToOne
   private PermissionContext permissionContext;

   public static class PermissionPk implements Serializable{
      public String id;        
      public PermissionContextPk permissionContext;
      // ... eq and hashCode here ...
   }
}

and what I get is:

 org.hibernate.AssertionFailure: Unexpected nested component on the referenced entity when mapping a @MapsId: PermissionContext 
    Caused by: org.hibernate.AssertionFailure: org.hibernate.AssertionFailure: Unexpected nested component on the referenced entity when mapping a @MapsId: PermissionContext

does anybody know if this is a hibernate bug and I should post it on their issue tracking system (and pray that I would be able to update to given hibernate version) or is there something fundamentally wrong with my way of binding the entities?

I've checked it with the hibernate implementation on EAP 6.1 (4.2.0) as well as on wildfly (don't really know which one.)

score 2 · Accepted Answer · answered Sep 17 '14 at 10:35

Ok, so this is what I found so far :

Thanks fr my friend : https://hibernate.atlassian.net/browse/HHH-5764 which most probably is the reason for this behaviour.

And I found a workaround :

Permission.java:

@Entity
@IdClass(PermissionPk.class)
public class Permission{

   @Id
   private String id;

// for the next 3 fields there are no public acessors, so the public API of the class was not changed !
   @Id
   @Column(name = "PROJECT")
   private String projectId;

   @Id
   @Column(name = "PERMISSIONCONTEXTTYPE")
   private String permissionContextTypeId;

   @Id
   @Column(name = "PERMISSIONCONTEXT")
   private String permissionContextId;


   @JoinColumns ({
            @JoinColumn (name = "PROJECT", referencedColumnName = "PROJECT", updatable = false, insertable = false),
            @JoinColumn (name = "PERMISSIONCONTEXTTYPE", referencedColumnName = "PERMISSIONCONTEXTTYPE", updatable = false, insertable = false),
            @JoinColumn (name = "PERMISSIONCONTEXT", referencedColumnName = "ID", updatable = false, insertable = false)
        })
   @ManyToOne
   private PermissionContext permissionContext;

   public static class PermissionPk implements Serializable{      
// previously they where private as well, but removed public constructor for the sake of simplicity of the question - so no changes where necesary in public API of the class !
      private String id;        
      private String projectId;        
      private String permissionContextTypeId;
      private String permissionContextId;

   public PermissionPk () {}

    public PermissionPk (String aId, PermissionContextPk aPermissionContext) {
        this.id = aId;
        permissionContextId = aPermissionContext.id;
        permissionContextTypeId = aPermissionContext.permissionContextType.id;
        projectId = aPermissionContext.permissionContextType.project;
    }  
... eq and hashCode here ...
   }
}

The good thing about this workaround is that it does not change the public API of the class in any way (the only change was that I needed to make fields in Pk's of context and contexttype visible to the PermissionPk - they where private before with only a public constructor [but again simplified for the question]), nor did it change the jpql queries, and at the same time workaround is scalable (to any tier amount - as long as every even pk does not contain another pk), so if the bug will be resolved it will be easy to remove the workaround.

I would still gladly accept any comments on either my workaround or the question in itself.

I have the same problem that yours. Your 1st workaround looks fine, but don't you have to use it at the class "PermissionContext"? Wich is the one that Hibernate is complaining about (due to the 2nd level nest of PKs). The class "Permission" is 3rd level. — choquero70, Oct 14 '14 at 18:00
Another workaround I've thought is to remove the Id annotatons of the composed PK, and to add a simple Id field as PK, autogenerated, and make the original fields of the composed PK unique (with a constraint at entity). — choquero70, Oct 14 '14 at 18:05
you can add it on Permission Context - it will work as well (and as it doesn't change anything in public api it is non-intrusive), but it works on Permission as well - cause then you don't have a 2nd level composite PK counted from the Permission down in the line (it is not a problem in PermissionContext as it only has one composite PK in it's hierarchy - the PermissionContextType). Your second workaround is ok only if you have the ability to alter the database :). — psychollek, Oct 15 '14 at 15:50

score 0 · Answer 2 · answered Sep 23 '14 at 17:01

Today I found another workaround :) You can omit @IdClass entirely and use hibernate specific ability to create composite keys on the fly as apparently it is not affected by this bug. The drawback here is that:

it is entirely Hibernate specific not covered by JPA at all.
you cannot do em.find(ClassName.class,new ClassPk(args...)) as there is no ClassPk at all.

But if you could use anything else than hibernate you could just as well use something without this bug - so probably 1 is not a problem really. and there is a possibility that you don't really need the em.find for this entity (or can live with creating it thru session or jpql query).

JPA 2 Hibernate mapping with composite key in primary key using @IdClass with 3 tier structure

2 Answers2