<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 22 mai 2012, at 08:33, Gunnar Morling wrote:</div><blockquote type="cite"><p>Right. I guess what I'm just not totally comfortable with is the fact that, when looking at an entity, it gets a bit more complicated to understand whether a @NotNull constraint is validated or not. </p><p>By defining a validation group such as @PreUpdate and putting the @NotNull constraint into that group a user could solve the issue in an easy-to-understand way leveraging the existing mechanisms.</p><p>I see that such a feature would probably help to give a better "it-just-works" experience. But one could also argue that using a sequence (or another id generation strategy not providing a value before the insert) and a @NotNull constraint within a group which is validated upon insertion represents an inconsistency within the data model.</p><p>On a more practical side: How would a JPA provider implement that feature? The simplest would probably be to validate all constraints and then ignore any id-related violations based on the chosen generation strategy. Or do you think we should define a way to control whether certain constraints are to be excluded by the BV runtime?</p></blockquote><br></div><div>I understand we are talking about a trade-off between a bit of magic vs usability. We all know Bean Validation pretty well and in 10 mins we know that using a group can work around that. I could understand the full problem in 15 mins because I happen to be in both the JPA and the BV expert group. But how long would it have taken you? The NetBeans team got it backwards for example.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I don't want to see a blog post down the line claiming that Java EE designers are stupid morons not to take care of such trivial issue and have them explaining why platform X or Y is better because of those details.</div><div><br></div><div>About the implementation, the JPA provider would pass a custom TraversableResolver that would return false to isReachable(…) when the node is the identifier property of the entity instance.</div></body></html>