在选择过程中绕过 Bean 验证，但不在插入/更新过程中绕过 Bean 验证
我正在使用 Glassfish 3.1.1（JSF 2、JPA 2、EclipseLink、Bean Validation）。
我正在尝试使用 Bean Validation API 和以下注释来实现验证：@Past、@Future 和 @NotNull。
它在插入或更新期间工作正常。不幸的是，当我尝试选择具有一些不正确值的实体时，我遇到了这个异常：
[#|2011-12-20T10:18:30.286+0100|WARNING|glassfish3.1.1|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=36;_ThreadName=Thread-2;|DTX5014: Caught exception in beforeCompletion() callback:
javax.validation.ConstraintViolationException: Bean Validation constraint(s) violated while executing Automatic Bean Validation on callback event:'preUpdate'. Please refer to embedded ConstraintViolations for details.
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.validateOnCallbackEvent(BeanValidationListener.java:90)
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.preUpdate(BeanValidationListener.java:72)
我在规范上看到我可以使用此属性 javax.persistence.ValidationMode 禁用 JPA 验证，但是 如何在选择期间禁用验证，但在插入或更新期间禁用验证？
预先感谢您的帮助。
I'm using Glassfish 3.1.1 (JSF 2, JPA 2, EclipseLink, Bean Validation).
I'm trying to implement validation with the Bean Validation API with these annotations: @Past, @Future and @NotNull.
It works fine during insert or update. Unfortunately, when I try to select en entity which have some incorrect values, I have this exception:
[#|2011-12-20T10:18:30.286+0100|WARNING|glassfish3.1.1|javax.enterprise.resource.jta.com.sun.enterprise.transaction|_ThreadID=36;_ThreadName=Thread-2;|DTX5014: Caught exception in beforeCompletion() callback:
javax.validation.ConstraintViolationException: Bean Validation constraint(s) violated while executing Automatic Bean Validation on callback event:'preUpdate'. Please refer to embedded ConstraintViolations for details.
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.validateOnCallbackEvent(BeanValidationListener.java:90)
at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.preUpdate(BeanValidationListener.java:72)
I saw on the spec that I can disable JPA validation with this property javax.persistence.ValidationMode but how to disable validation during select but NOT during insert or update?
Thanks in advance for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
问题是持久性上下文中的任何内容都将被验证。
您可以通过在事务之外的不同 EntityManager 中读取对象来避免将对象添加到持久性上下文中，或者在读取它们的查询上使用“eclipselink.read-only”提示。
尽管正在验证没有更改的对象，但这确实看起来很奇怪。如果是这种情况，那么可能会记录一个错误。
The issue is that anything in the persistence context will be validated.
You could avoid adding the objects to the persistence context, by reading them in a different EntityManager outside of a transaction, or use the "eclipselink.read-only" hint on the query reading them.
It does seem odd though that objects without changes are being validated. If this is the case, then perhaps log a bug.
几条评论。
首先，验证模式（javax.persistence.validation.mode）仅决定验证模式：自动、回调或无。
您所追求的是属性：
允许您定义每个主要回调。但这些都与选择无关。
不过，看看您的错误，preUpdate 似乎失败了。你到底是怎么得到这个错误的？
Several comments.
First, the validation mode (javax.persistence.validation.mode) only determines the validation mode, auto, callback or none.
What you are after are the properties:
which allow you to define for each of the main callbacks. None of these are related to selects though.
Looking at your error though, the preUpdate seems to fail. What and how exactly do you get this error?
好的，我的应用程序中的日期也有类似的问题。我将交易实体和术语实体关联在一起，如果交易变旧，我会将其移至历史交易。因此，我希望旧的条款（期间）保留在数据库中，但也防止创建具有过去日期的新条款。因此术语只能自然地变老，而不能像过去一样由用户创建。我考虑在 Term 的开始/结束日期上使用 @Future 是否可以正常工作。
在开发时很难在应用程序中测试它，因为我需要等待Term变旧，然后将Transaction移动到历史交易。
Ok I have similar issue with Dates in my application. I have Transaction entity and Term entity associated together and if Transaction gets old I am moving it to Historical Transaction. So I want that old Terms (Periods) stay in database, but also to prevent creation of new Terms with dates in the past. So Terms can only naturally getting older, and not be created as in the past by user. I consider whether using @Future on start/end dates of Term will work correctly.
This is hard to test it in app while developing, as I need to wait for Term to gets older and then move Transaction to Historical Transaction.