This is a missing feature in JPA 1.0 and JPA 2.0. Maybe this can be overcome with EntityListeners …

Anythought ?

Instead of assign the uid inside the constructor you could use an EntityListener. This way the uid is only generated before persist or when somebody calls hashCode() or equals().

@MappedSuperclass
@EntityListeners({AbstractEntity.AbstractEntityListener.class})
public abstract class AbstractEntity implements Serializable {

@Id
@Column(length=36)
private String uid;

@Override
public boolean equals(Object o) {
return (o == this || (o instanceof AbstractEntity && uid().equals(((AbstractEntity)o).uid())));
}

@Override
public int hashCode() {
return uid().hashCode();
}

String uid() {
if (uid == null) {
uid = new UUID().toString();
}
return uid;
}

public static class AbstractEntityListener {
@PrePersist
public void onPrePersist(AbstractEntity abstractEntity) {
abstractEntity.uid();
}
}
}

Really nice to see so many responses here. One of the things which triggered me to write this blog was that I always went for the ‘easy’ way in terms of selecting a primary key strategy without giving it much thought. I’m no UUID expert in any way although I found it very useful and I’ll use it again more often.

@Micheal: Do you have an example of your pool implementation?

@Jens: We felt comfortable to use the java.util.UUID implementation for our specific use-case, but I agree with you that for true universal uniqueness you should take a different implementation. Thanks for the links!

1. Performance can be an issue: Yes, it can, but grabbing a sequence from the DB creates a bigger issue (2 calls per new insert, depending on the RDBMS platform). This can be easily remedied by writing a simple UUID pool object which generates the UUIDs in batch, and doles them out on request. When the pool runs low/out, regenerate.

2. Ordering/Sorting. Indeed, you really cannot order by the primary key in the case of a UUID. But then again, why does one usually order by primary key? Sequential primary keys tend to indicate the order of entity creation. Good DB design principles include having a created_date and a modify_date column as part of the entity (depending on your needs and requirements, of course, but I’d say this is mostly true). With this in mind, you CAN order by the create date.

3. cannot test if a record has already been persisted by checking if the Id field has been set. Uhm, you can write a @GenericGenerator to generate the uuid if you’re using a JPA provider other than hibernate, and it wouldn’t be hard at all. The UUID is only set upon insert call to the DB, so you can do this check. But the OP is right, I question a design that checks for the existence of a PK being set.

My $0.02. Reposting to my blog

-Michael

http://wiki.eclipse.org/EclipseLink/Examples/JPA/CustomSequencing

For an interesting discussing about the opinion of the Hibernate developers see this post on the hibernate forum: https://forum.hibernate.org/viewtopic.php?t=967211.

If you need universal uniqueness, you have to rely on a third party UUID library like http://johannburkard.de/software/uuid/ or http://jug.safehaus.org/, which evaluate the network adapter’s MAC address to build a Version 1 UUID using platform dependend code.

>UUIDs are not guessable

If you use UUID Version 1 as mentioned above, this might not hold, see http://en.wikipedia.org/wiki/Uuid#Version_1_.28MAC_address.29

I’ll like to add another Con:

By using UUID, you introduce another dependency to your Domain class – this might be a problem if you for example want to transmit instances of these classes via Gilead to GWT client side code.

I had this problem once and solved it by setting the UUID in the DAO’s insert/update method if it is null.