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

Gunnar Morling gunnar at hibernate.org
Tue Feb 6 15:07:12 EST 2018


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


More information about the hibernate-dev mailing list