[bv-dev] BVAL-234 @NotNull @Id for JPA and Bean Validation

[Peter Davis]

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.

Thanks,

Peter Davis