Skip to content

Understanding Composite-id with JPA Identifiers @Id Vs @EmbeddedId Vs @IdClass

Note – If you’re looking for Hibernate Composite-Id example using xml configuration, read our earlier post here.

Entities must define an id field. Typically a generated id is fine for most cases, but sometimes we need to add multiple fields corresponding to the database primary key. (legacy database?). The id can either be simple or composite value. JPA provides three Strategies with annotations, it’s almost same as Hibernate annotations. Here’s a small tutorial: -

@Id: single valued type – most commonly used
@IdClass: map multiple fields to table PK
@EmbeddedId map PK class to table PK

The last two cases use a hibernate Composite-id; the PK classes must implement Serializable, override equals() and hashCode(). Let’s look at some examples with a Person entity: -

@Id
This is the simplest and most commonly used scenario

@Entity
public class Person{
   @Id
   private Long id;
   private name;
}

@IdClass
Here, it maps multiple fields of persistent entity to PK class

@Entity
@IdClass(PersonPK.class)
public class Person {
    @Id
    private Long name;
    @Id
    private Long dateOfBirth;
}

public class PersonPK implements Serializable {
    private Long Long name;
    private Long dateOfBirth;
    public boolean equals(Object obj);
    public int hashCode();
}

@EmbeddedId
Here, the primary key is formal member (a first class variable) of the persistent entity

@Entity
public class Person {
   @EmbeddedId
   private PersonPK key;
}
@Embedded
public class PersonPK implements Serializable {
    private Long name;
    private Long dateOfBirth;
    public boolean equals(Object obj);
    public int hashCode();
}

Note – all the above imports are from javax.persistence.* and not org.hibernate.*

Now, isn’t that so much simpler than the verbose, confusing Hibernate xml configuration?

Choosing @EmbeddedId or @IdClass would be a matter of case by case basis.

  1. Firstly, You end up having same kind of database schema for both, it’s just a matter of choice
  2. @EmbeddedId should be used when the combined pk is either a meaningful entity itself or it reused in your code.
    @IdClass is useful to specify that some combination of fields is unique but these do not have a special meaning.

You must be thinking that this is still a simple example. Things get a little tricky when the composite ids are foreign keys themselves! We’ll see that in Part 2 of this article.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

2 Comments

  1. Ward wrote:

    Dear Priyatam,

    Thank you for this great article.
    It would be great if you finished Part 2 of this article.

    Do you have any tips for implementing the solution where composite ids are foreign keys themselves, cause I’ve been struggling with solving this problem for a week now.

    Thank you very much,
    Ward
    Belgium

    Wednesday, January 28, 2009 at 5:49 am | Permalink
  2. James wrote:

    Any luck on the second part of this article? I’d love to see it down with foreign keys!

    Tuesday, July 7, 2009 at 8:52 pm | Permalink

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*