2012/5/21 Emmanuel Bernard <emmanuel@hibernate.org>:
>
> On 21 mai 2012, at 21:06, Gunnar Morling wrote:
>
>> 2012/5/21 Emmanuel Bernard <emmanuel@hibernate.org>:
>>>
>>> On 15 mai 2012, at 19:50, Gunnar Morling wrote:
>>>
>>>> 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 think you misunderstood something. If sequence, table generation or any in memory generation logic is used, then @NoNull will indeed be validated in option #3. In fact, database trigger and column id generations are the only one that would disable validation.
>>
>> Ah, I see. Indeed I thought that you meant to disable validation of
>> @NotNull in any case. If the behavior depends on the applied id
>> generation strategy, #3 makes more sense.
>>
>> I'm not sure, does the JPA spec define that sequence values are always
>> to be prefetched? Otherwise I could imagine situations where an
>> allocation size of 1 is used, which would allow to fetch the sequence
>> just within the INSERT statement. In that case I think the constraints
>> again couldn't be validated.
>
> The JPA provider implementation would know such thing and act accordingly.

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?

--Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev