JPA ExceptionTranslation issue-Not Translating PersistenceException:unique constrait

[pcl]

Patrick,

Re-reading the original description I believe you are correct, this is a unique constraint violation on a non id field. This type of issue doesn't have a specific JPA exception so a general PersistenceException is the closest fit.

In this case there isn't much we can do without looking at the wrapped SQLException. We aren't doing that since the exception translator doesn't know the underlying database and won't be able to interpret the error code. So the best we can do is to translate to a generic "unknown" type exception in the Spring exception hierarchy which is JpaSystemException.

Hi,

If OpenJPA were throwing an org.apache.openjpa.persistence.ReferentialIntegrit yException instead of just a PersistenceException, would that change things?

-Patrick

[pcl]

Spring's exception translation sits on top of JPA at the DAO or Repository level and is optional. The benefit is that your service layer only have to deal with exceptions from a single exception hierarchy -- Spring's DataAccessException hierarchy -- regardless of the underlying data access technology. This is definitely valuable when you mix JDBC and ORM in the DAO layer.

Hi,

Yes, I understand the value of Spring's exception translation facilities. I'm wondering more about implementation details. Since OpenJPA already translates 100% of the exceptions thrown (including exceptions thrown from within lazy loading and such from direct access of persistent data in a managed instance), it would seem that we could do a more optimal integration between Spring and OpenJPA, such that OpenJPA translated exceptions directly from OpenJPA-internal types to Spring types, instead of the current OpenJPA-internal => JPA spec + extensions => Spring types.

Does that make sense?

-Patrick

[trisberg]

Yes, I understand the value of Spring's exception translation facilities. I'm wondering more about implementation details. Since OpenJPA already translates 100% of the exceptions thrown (including exceptions thrown from within lazy loading and such from direct access of persistent data in a managed instance), it would seem that we could do a more optimal integration between Spring and OpenJPA, such that OpenJPA translated exceptions directly from OpenJPA-internal types to Spring types, instead of the current OpenJPA-internal => JPA spec + extensions => Spring types.

Yes, we could translate any OpenJPA specific exceptions in the OpenJpaDialect class. That would definitely be valuable.

If OpenJPA were throwing an org.apache.openjpa.persistence.ReferentialIntegrit yException instead of just a PersistenceException, would that change things?

That would work with the above scenario and we could translate that directly into a DataIntegrityViolationException.