[hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Steve Ebersole]

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 at hibernate.org> wrote:

> 2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve at 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/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L141
> ).
>
>> 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 at 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/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>