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&gt; 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.