I'm not sure I would call them separate. They are clearly linked. Look at
it this way, if we export various "validation" constraints to the database
(DDL) it is, practically speaking, a performance overhead to also perform
those checks in memory. Right? This is, I think, the distinction you may be
missing in terms of DDL as a separate mode - only do these checks once, at
the database level.
Can all such validations be handled at the database level via contraints?
No of course not - but the vast majority in fact can.
On Tue, Feb 6, 2018, 7:52 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
2018-02-06 14:41 GMT+01:00 Steve Ebersole
<steve(a)hibernate.org>:
> The reasoning is that the 2 BV modes you mention make no mention of also
> applying constraints to the database. It would be surprising for that to
> happen. I can see the argument for AUTO, but absolutely not for CALLBACK.
>
I think that a) "trigger validation upon insert/update" and b) "propagate
constraints to the DDL" are two separate concerns which should be handled
independently.
I.e. ideally I'd keep the "validation mode" property solely focused on a)
(i.e. not have that DDL enum member) and control b) (which is as you say
not defined by the spec) via a separate property. In fact, ORM already has
a property applying to b), "hibernate.validator.apply_to_ddl", although
it seems linked to "legacy Hibernate Validator" as per a log statement in
TypeSafeActivator (
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
).
> Also important is the distinction that hibernate accepts multivalued
> validation modes, whereas BV does not if I remember correctly... Although
> in my opinion it absolutely should.
>
"validation mode" is defined by JPA, not BV. As per above I don't think it
needs to be multi-valued, those two aspects can be handled separately.
>
> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris(a)hibernate.org> wrote:
>
>> Gunnar -
>>
>> I don't particularly see a reason why we cannot as it seems we're
>> handling the CALLBACK mode with no BV provider present earlier in the
>> code path. I'm fine changing it.
>>
>> Chris
>>
>>
>> On 02/04/2018 07:21 AM, Gunnar Morling wrote:
>> > Hi,
>> >
>> > If the JPA validation mode is set to CALLBACK, BV constraints such as
>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>> >
>> > Instead, in TypeSafeActivator, the BV constraints are only considered
>> for
>> > DDL if the validation mode is DDL or AUTO [1].
>> >
>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
>> > silently ignoring it if no BV provider is present), so it's the
>> setting I
>> > usually recommend. I think constraints should also be propagated to
>> DDL in
>> > this mode, so I'm wondering whether there a specific reason for the
>> current
>> > behaviour or wether we can change it?
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> > [1]
>> >
>>
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>