[bv-dev] BVAL-234 @NotNull @Id for JPA and Bean Validation
Emmanuel Bernard
emmanuel at hibernate.org
Tue May 22 11:05:41 EDT 2012
On 22 mai 2012, at 16:26, Peter Davis wrote:
> On May 22, 2012, at 7:11, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> Think about regular developers, they probably don't really know that an id can be populated after the object is saved in the database. So when they see such an exception popping up, they expect a bug in either the JPA or Bean Validation provider. Once they realize it might not be a bug, they have to find out the fairly verbose workaround.
>>
>> With option #3, the issue is silently ignored. Is that bad? My claim is that it is not bad because the value is generated anyways and the probability of having a erroneous constraint is low. And as Sebastien proposed we could do a post-create checking for the id property and give the feedback to the user.
>
> I've been watching this conversation because I myself have just
> created a project with several @Generated @Ids on which I can't use
> @NotNull. At first I thought #3 (w/ TraversableResolver) was the more
> elegant solution. But then I remembered that many projects (such as
> mine) don't *rely* on the JPA provider invoking validations. In fact,
> doing so causes problems because the exceptions can occur at
> unexpected times and it becomes very difficult (for a web app) to
> highlight invalid fields when the propertyPaths are relative to an
> arbitrary root. My point is, we rely mostly on invoking validation
> from the service layer (manually or with method validation / AOP via
> Spring). JPA validation provides a comfortable last-chance sanity
> check and a convenient way to map @NotNull to @Column(nullable=false).
>
> So a TraversableResolver would be useless to my projects and we'd have
> to use groups anyway.
>
It depends what your AOP layer is doing. If it executes validation before the transaction is committed - or before flush() is called - then yes, you need groups. But I don't see your APO layer validating newly created and stored objects. Can you detail your use case where you would end up in the situation we are discussing.
More information about the beanvalidation-dev
mailing list