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

[Steve Ebersole]

On Tue, Feb 6, 2018 at 9:58 AM Gunnar Morling <gunnar at hibernate.org> wrote:

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

Because a user picked CALLBACK, which has a very specific meaning.  Its
like me asking a framework to do (a) and it chooses to also do (b).  (b)
might be nice and it might even be helpful, but I did not ask it to do
(b).  And even worse if the framework actually provides a way to ask for
(b).



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

Ok, then the crux here is that you do not like that we make a JPA-defined
single-valued setting into a multi-valued setting.  Ok, I can understand
that.  So then what is your suggestion?  Because I did not like your
original suggestion for the reasons I have stated, unless I mis-read your
suggestion




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