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

[Gunnar Morling]

It's not quite clear to me what your preferred alternative is. Not being
able to export constraints to DDL when using the safest validation mode
(CALLBACK) is not desirable IMHO.

+1 to hear what others think.

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

> I personally think 2 settings to control 1 thing is fugly, but if there is
> a consensus that is fine.  Bu so far its just been you saying that.
>
> On Tue, Feb 6, 2018 at 10:09 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> > All of those are valid options.  But I think Gunnar's suggestion misses
>> #3, although I certainly maybe just missed that in his email.  Gunnar?
>>
>> You'd have this:
>>
>> - No validation: validation mode = NONE, hibernate.validator.apply_to_ddl
>> = false
>> - In-memory validation: validation mode = AUTO|CALLBACK, hibernate.
>> validator.apply_to_ddl = false
>> - In-db validation: validation mode = NONE, hibernate.validator.apply_to_ddl
>> = true
>> - In-memory && in-db validation: validation mode = AUTO|CALLBACK,
>> hibernate.validator.apply_to_ddl = true
>>
>> Hibernate's validation mode DDL would be deprecated, being an alias for
>> hibernate.validator.apply_to_ddl = true, if present.
>>
>> 2018-02-06 17:01 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>>> On 6 February 2018 at 15:34, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>> > We tend to do this argument where it "not what we would do".  Well not
>>>> > everyone is us :)
>>>>
>>>> Not understanding what you mean with that. I'm well aware others might
>>>> have other opinions, in fact I'm suggesting to allow people more
>>>> control than what you established should be right?
>>>>
>>>
>>> Is it valid for a user to want *just* DDL-based validation?  How would
>>> that work in Gunnar's request?
>>>
>>> That's my point.  I mean to me there is:
>>>
>>>    1. No validation
>>>    2. In-memory validation
>>>    3. In-db validation
>>>    4. In-memory && in-db validation
>>>
>>> All of those are valid options.  But I think Gunnar's suggestion misses
>>> #3, although I certainly maybe just missed that in his email.  Gunnar?
>>>
>>>
>>>
>>>> > Also you are arguing about optimizing the exception case.  The
>>>> majority case
>>>> > is that the in-memory validations will (a) happen and (b) pass and
>>>> then we
>>>> > still have the db validations happening.
>>>>
>>>> I'm aware. And that's why I said "it might be redundant ... but then
>>>> you'd not need validation".
>>>> Obviously everyone needs validation, so optimising the exception case
>>>> might be important - especially since like I said it's much cheaper to
>>>> do so in in local memory rather than have a round trip to the RDBMS to
>>>> figure it out, and consume precious RBDMS resources to have it do the
>>>> same job.
>>>>
>>>
>>>
>>>    1. No its not "obvious everyone needs validation".  I've worked on a
>>>    few "raw input" systems (data imports, data transfers, etc) where you'd
>>>    actually want absolutely no validation.  I'm sure there are other stories
>>>    out there where conditions call for no validation..
>>>    2. "so optimising the exception case *might* be important" - might,
>>>    absolutely.  And then the rest of this comment... I mean you assume so many
>>>    things about that app, the environment, etc
>>>
>>>
>>