Applying validation at both levels has a few benefits:
- DDL means that constraints are also applied to non Java apps or even
third party apps not using Bean Validation
- applying the constraint during the CRUD events provides more
contextual exception reports, better than what we can do by converting
the DB exception.
- constraints more elaborated don't have full counter-parts in DDL.
At the time, I did find enhancing an existing property better than introducing a
new one. I still do for what it's worth.
Emmanuel
On Mon 2013-03-04 8:01, Steve Ebersole wrote:
Partially. What it also says is too perform double checking
(callback and db constraints) when BV is present.
I guess the reason you want to allow both is because we do not (and
really can not) convert all validations to db contraints.
My point is just that Set<ValidationMode> seems total overkill when
there is exactly (at best) one valid combination of options. Could
more easily have been handled with using the JPA validation mode
setting as per spec (not our special treatment of it) *plus* a
custom setting that says to convert validations to ddl contraints
whenever possible.
On Mon 04 Mar 2013 07:53:34 AM CST, Emmanuel Bernard wrote:
>I don't follow you. It seems to make sense to me to have ddl and
>callback.
>
>It says validate entities on CRUD events, apply database generation in
>accordance to the constraints and raise an exception if BV is not
>present in the CP.
>
>
>On Mon 2013-03-04 7:36, Steve Ebersole wrote:
>>My concern is not the additional option.
>>
>>My concern is the allowance of multiple selections. The only combo
>>that ever even conceivably makes sense is "ddl" and
"callback"
>>together. But I am questioning how sensible it is really to have
>>those 2 together. IMHO not much sense at all.
>>
>>So IMO we ought to be deprecating the ability to have multiple
>>selections here.
>>
>>
>>On Mon 04 Mar 2013 07:21:26 AM CST, Emmanuel Bernard wrote:
>>>Our impl allow multiple choices to be able to add ddl as an additional
>>>behavior as it (was) not defined in the spec.
>>>
>>>And indeed, auto uses the degraded mode and callback forced BV to be
>>>used and raise an exception if it is not present. I can see apps deciding
>>>for one or the other.
>>>
>>>Emmanuel
>>>
>>>On Fri 2013-02-22 21:38, Hardy Ferentschik wrote:
>>>>
>>>>On 22 Jan 2013, at 9:17 PM, Steve Ebersole <steve(a)hibernate.org>
wrote:
>>>>
>>>>>Kind of. What I mean is that the HEM integration code is allowing
Set <ValidationMode>. So our impl allows a value like "auto, ddl" or
other combos. I am not able to grok why we allow multiples.
>>>>
>>>>I think this is a Hibernate specific "feature" to support also
ddl generation. The idea is to say something like "callback,ddl" to enable
validation and application of DDL constraints.
>>>>Emmanuel might know more. With JPA 2.1 and the DDL stuff part of the spec
I would assume there are are other explicit options to enable/disable these features.
>>>>
>>>>>Also auto and callback are slightly different. callback causes an
error if no bv provider is available whereas auto then skips validation.
>>>>
>>>>Hmm, seems wrong indeed, but maybe that's the difference in the end.
Looking at "3.6.1.1 Enabling Automatic Validation" of the spec for the auto mode
it is not explicitly mentioned
>>>>that an exception should be thrown whereas for callback it is. Whether
this is international or just badly written I don't know. Maybe something to clarify
in the spec.
>>>>Don't we have someone in the JPA expert group ;-)
>>>>
>>>>--Hardy
>>>>_______________________________________________
>>>>hibernate-dev mailing list
>>>>hibernate-dev(a)lists.jboss.org
>>>>https://lists.jboss.org/mailman/listinfo/hibernate-dev