Re: [bv-dev] BVAL-234 @NotNull @Id for JPA and Bean Validation
On 22 mai 2012, at 08:33, Gunnar Morling wrote:
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.
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.
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.
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?
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.
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 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.
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.
Attachments:
- attachment.html (text/html — 2.8 KB)