2012/5/15 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 15 mai 2012, at 12:38, Hardy Ferentschik wrote:
> Is option #3 even possible within the JPA spec? One would need meta information about
the id property
> (which generation type and how exactly this type behaves regarding the id generation
time). I don't think there
> is a way to do this with the JPA api. Also JPA does not even explicitly define the
behavior of the different strategies.
Remember that the TraversableResolver used in pre-* events is implemented by the JPA
provider itself. It's very easy for the implementation
to tap provider specific metadata (most likely not exposed). We don't need JPA to
expose the API.
>
> Disabling the validation per default can also backfire in the cases where a user
"knows" that a certain strategy
> will generate the id pre insert. In this case it would be valid to add @NotNull.
True but that would definitely make the application non portable from a JPA point of
view.
I also find disabling validation of @NotNull by default problematic.
If I'm for instance using sequences for id generation, then @NotNull
should be validated upon insertion. But relying on sequences is IMO
per se not portable; so when deciding to use them, I'd also expect
@NotNull to be validated.
I'm in favor of option #1; users can precisely configure the behavior
they need with the existing constructs (validation groups), so I don't
really see the need for adding something to the spec.
Regarding #2, I'm not sure whether that offers much value. But if
going down that road, I think I'd do it consequently and introduce
@PreInsert, @PreUpdate and @PreDelete.
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev