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

[Steve Ebersole]

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