我想我发现两个不同的JPA实现在约束违规和回滚方面的工作方式不同。
@Test(expectedExceptions = @@.class) // CVE or RB?
public void testXXX() {
final EntityManager manager = LocalPU.createEntityManager();
try {
final EntityTransaction transaction = manager.getTransaction();
transaction.begin();
try {
manager.persist(<wrong>); // this is where CVE coming from
transaction.commit(); // this is where RB coming from
} catch (RollbackException re) {
// <---------------------------------------- hibernate here
throw re;
} catch (ConstraintViolationException cve) {
// <---------------------------------------- eclipselink here
transaction.rollback();
throw cve;
} catch (Exception e) {
transaction.rollback();
e.printStackTrace(System.err);
Assert.fail(e.getMessage());
}
} finally {
manager.close();
}
}
哪种实施正常?
@Entity
@Table(name = "NAME_MUST_NOT_BE_NULL")
public class NameMustNotBeNull {
protected NameMustNotBeNull() {
this(null);
}
public NameMustNotBeNull(final String name) {
super();
this.name = name;
}
@Id
@GeneratedValue(strategy = GenerationType.TABLE,
generator = "NAME_MUST_NOT_BE_NULL_ID_GENERATOR")
@TableGenerator(name = "NAME_MUST_NOT_BE_NULL_ID_GENERATOR",
table = PrimaryKeyValue.TABLE,
pkColumnName = PrimaryKeyValue.PK_COLUMN_NAME,
valueColumnName = PrimaryKeyValue.VALUE_COLUMN_NAME,
pkColumnValue = "NAME_MUST_NOT_BE_NULL_ID")
@NotNull
@XmlTransient
private Long id;
@Basic(optional = false)
@Column(name = "NAME", nullable = false)
@NotNull
private String name;
}
public class NameMustNotBeNullTest {
@Test(expectedExceptions = RollbackException.class)
public void testNullName() {
final EntityManager manager = LocalPU.createEntityManager();
try {
final EntityTransaction transaction = manager.getTransaction();
transaction.begin();
try {
final NameMustNotBeNull entity = new NameMustNotBeNull(null);
try {
manager.persist(entity);
} catch (ConstraintViolationException cve) {
System.out.println(cve.toString());
}
transaction.commit();
Assert.fail("persisted with null name");
} catch (RollbackException re) {
System.out.println(re.toString());
throw re;
} catch (Exception e) {
transaction.rollback();
e.printStackTrace(System.err);
Assert.fail(e.getMessage());
}
} finally {
manager.close();
}
}
}
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="localPU" transaction-type="RESOURCE_LOCAL">
<!-- I'm testing with one of following providers uncommented -->
<!--<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>-->
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<class>....persistence.NameMustNotBeNull</class>
<properties>
<property name="javax.persistence.jdbc.driver"
value="org.apache.derby.jdbc.EmbeddedDriver"/>
<property name="javax.persistence.jdbc.url"
value="jdbc:derby:memory:corrsDB;create=true"/>
<!--<property name="javax.persistence.jdbc.user" value=""/>-->
<!--<property name="javax.persistence.jdbc.password" value=""/>-->
<!-- eclipselink -->
<property name="eclipselink.create-ddl-jdbc-file-name" value="target/createDDL.jdbc"/>
<property name="eclipselink.ddl-generation" value="create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="both"/>
<property name="eclipselink.drop-ddl-jdbc-file-name" value="target/dropDDL.jdbc"/>
<property name="eclipselink.logging.level.sql" value="INFO"/>
<property name="eclipselink.logging.parameters" value="false"/>
<property name="eclipselink.target-database" value="Derby"/>
<!-- hibernate -->
<property name="hibernate.archive.autodetection" value="class" />
<property name="hibernate.format_sql" value="true" />
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
<property name="hibernate.show_sql" value="false" />
<property name="hibernate.dialect" value="org.hibernate.dialect.DerbyDialect"/>
</properties>
</persistence-unit>
</persistence>
Running ...NameMustNotBeNullTest
1월 17, 2013 11:45:14 오전 org.hibernate.validator.internal.util.Version <clinit>
INFO: HV000001: Hibernate Validator 4.3.0.Final
javax.validation.ConstraintViolationException: Bean Validation constraint(s) violated while executing Automatic Bean Validation on callback event:'prePersist'. Please refer to embedded ConstraintViolations for details.
javax.persistence.RollbackException: Transaction rolled back because transaction was set to RollbackOnly.
Running ...NameMustNotBeNullTest
1월 17, 2013 11:50:14 오전 org.hibernate.validator.internal.util.Version <clinit>
INFO: HV000001: Hibernate Validator 4.3.0.Final
javax.persistence.RollbackException: Error while committing the transaction
如您所见,两个提供商似乎都启用了Bean Validation。
EclipseLink在EntityManager#persist()
上抛出CVE并标记回滚。
并且Hibernate在EntityTransaction#commit()
上抛出RB。
答案 0 :(得分:8)
以下是有关您的行为的更详细信息来源。
根据JPA 2 specification(第102页)
如果validate方法返回的ConstraintViolation对象集不是 为空,持久性提供程序必须抛出包含对返回的ConstraintViolation对象集的引用的javax.validation.ConstraintViolationException,并且 必须将事务标记为回滚。
如果发现实体无效,则ConstraintViolationException会传播约束违规列表,这会暴露一组ConstraintViolations。
违规时将此异常包装在RollbackException中 在提交时发生。否则,ConstraintViolationException是 [由Hibernate Validator]返回(例如,在调用flush()时。)
此外,从jpa 2规格(第101页)
默认情况下,默认的Bean Validation组(组默认值)将根据预先存在和更新前的生命周期验证事件进行验证
把所有这些放在一起,我有点困惑,因为在我看来,HibernatePersistenceProvider的行为不遵循JPA 2规范,因为:
显然,在你的情况下,调用ConstraintViolationException
时(以及使用HibernatePersistenceProvider时)不会抛出persist
。
根据我的理解并回答你的问题:
(注意:我希望其他人可以确认或不同意我的分析)
重要编辑
我对自己的结论感到困惑。所以我试图重现OP所描述的行为,我无法立即重现这种行为。
我所做的与OP所描述的非常相似:
@NotNull
字段。@NotNull
字段保留()一个null为null的实例。persist()
操作抛出javax.validation.ConstraintViolationException
+将交易标记为rollback only
我的测试和测试之间的主要区别是描述OP是id生成。
在我成功的测试中,我使用了一个简单的@GeneratedValue
。
将id生成策略更改为:
@GeneratedValue(strategy = GenerationType.TABLE,
generator = "NAME_MUST_NOT_BE_NULL_ID_GENERATOR")
@TableGenerator(name = "NAME_MUST_NOT_BE_NULL_ID_GENERATOR",
pkColumnValue = "NAME_MUST_NOT_BE_NULL_ID")
我发现了OP描述的确切行为:
javax.validation.ConstraintViolationException
引发的persist()
。persist()
抛出的所有内容都没有异常。因此,当使用Hibernate + strategy = GenerationType.TABLE
时:行为是不同的。我很确定它不符合JPA2规范。
答案 1 :(得分:3)
两者都是正确的。 JPA允许提供程序在persist处抛出EntityExistsException,或者在flush / commit处抛出另一个PersistenceException,我一直假设覆盖数据库异常。我不知道Hibernate或你得到的完整错误,但我想数据库异常正在发生并被包装在RollbackException中。
这两个测试可能不相同 - ConstraintViolationException不是来自JPA,而是来自prepersist期间发生的验证(JSR-303)。您必须在EclipseLink测试中启用Bean验证实现(例如类路径上的hibernate-validator-4.0.1.GA.jar),这些实现可能未在Hibernate测试中启用。如果从一个bean中删除bean验证或将其添加到另一个,它们的行为应该更相似。