Re: [bv-dev] BVAL-234 @NotNull @Id for JPA and Bean Validation
On May 22, 2012, at 7:11, Emmanuel Bernard <emmanuel(a)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.
Thanks,
Peter Davis