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

[Gunnar Morling]

My question essentially is why is it alright to piggy-back the enablement
of the DDL constraint export on JPA's validation mode option (which only
has been designed with the lifecycle validation in mind) for AUTO but not
for CALLBACK?

It causes a few issues: When using CALLBACK (which is the right setting if
you really want to make sure that lifecycle validation happens), there's
currently no way to have the constraint export to DDL. JPA won't allow me
to specify { CALLBACK, DDL } (as it's only a single-valued option as you
say). So I'd have to use AUTO, at the risk of lifecycle validation being
not enabled silently if the BV provider is missing from the classpath for
some reason. Also the interaction with "hibernate.validator.apply_to_ddl"
is confusing, as this only can be used to turn off the DDL export of
constraints but enabling it (the default) doesn't itself guarantee that
this is happening.

2018-02-06 15:46 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> 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
>>>
>>>