Catching constraint violations in JPA 2.0

wen picture wen · May 23, 2010 · Viewed 14.7k times · Source

Consider the following entity class, used with, for example, EclipseLink 2.0.2 - where the link attribute is not the primary key, but unique nontheless.

@Entity
public class Profile {  
  @Id 
  private Long id;

  @Column(unique = true)
  private String link;

  // Some more attributes and getter and setter methods
}

When I insert records with a duplicate value for the link attribute, EclipseLink does not throw a EntityExistsException, but throws a DatabaseException, with the message explaining that the unique constraint was violated.

This doesn't seem very usefull, as there would not be a simple, database independent, way to catch this exception. What would be the advised way to deal with this?

A few things that I have considered are:

  • Checking the error code on the DatabaseException - I fear that this error code, though, is the native error code for the database;
  • Checking the existence of a Profile with the specific value for link beforehand - this obviously would result in an enormous amount of superfluous queries.

Answer

Pascal Thivent picture Pascal Thivent · May 23, 2010

When I insert records with a duplicate value for the link attribute, EclipseLink does not throw a EntityExistsException

Yes, and a JPA provider is not supposed to throw an EntityExistException in that case, you won't get an EntityExistException on something else than the primary key.

(...) but throws a DatabaseException, with the message explaining that the unique constraint was violated.

This is very WRONG from EclipseLink, a JPA provider should throw a PersistenceException or a subclass but certainly not a specific exception like o.e.p.e.DatabaseException. This is a bug and should be reported as such as I already mentioned in a previous answer.

This doesn't seem very usefull, as there would not be a simple, database independent, way to catch this exception. What would be the advised way to deal with this?

Same answer as above, see my previous answer.