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

[Steve Ebersole]

Well like I said, I understand your not liking that we reuse a JPA-specific
setting regarding the validation mode (single-valued) and expand it to
accept multiple values.  I just think its just as bad to use 2 different
settings.  2 wrongs don't make a right.

When you say "safest" you mean (I assume) in terms of JPA provider
portability.  Because otherwise, I'm sure you are already talking about a
Hibernate-specific feature.

My specific concern with your 2 setting approach?  Well what about when I
want to disable validation for whatever reason?  So I set
`javax.persistence.validation.mode=NONE` (because, you know, that's the
"safest").  But I still get constraints exported.  And I can hear the next
answer... big deal, you get it exported to the schema... who cares?  Well I
do.  I have a real problem with telling a framework to do something, and it
does something else.

I don't have a great answer.  But then again, I'm not the one suggesting a
change ;)

On Tue, Feb 6, 2018 at 2:07 PM Gunnar Morling <gunnar at hibernate.org> wrote:

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