How is a String "CALLBACK,DDL" considered "multiple
values" to an XSD?
I was referring to the dedicated <validation-mode> element, which is
restricted to the values AUTO, CALLBACK, NONE in that XSD and which can be
given at most once [1]. I can see though how it'd work with the
javax.persistence.validation.mode String property.
So, yeah, technically no change needed. Still quite subtle and very easy to
miss. Waiting a bit for some more feedback by others, if we decide to leave
it as is, we need at least to update the HV docs to describe this in more
depth (we only mention <validation-mode> but not that string property).
[1]
https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-...
.
2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
How is a String "CALLBACK,DDL" considered "multiple
values" to an XSD?
>
> Look, I don't mind revisiting a change here. I really have no horse n
> this race - this is not even my code originally. TBH I thought this was
> code that you did. So I don't mind changes here if there is a consensus.
> But let's use real reasons ;)
>
> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
>
>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>
>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
>>
>>> Of course you can. `mode = CALLBACK,DDL`
>>>
>>> You mean that you cannot using single-valued setting
>>>
>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling <gunnar(a)hibernate.org>
>>> wrote:
>>>
>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve(a)hibernate.org>:
>>>>
>>>>> Ok, so this is the crux then because it really comes down to whether
>>>>> you
>>>>> believe whether it is valid to *only* export the annotation-based
>>>>> validations as DDL.
>>>>>
>>>>> And keep in mind that this code is basically unchanged from all the
way
>>>>> back to the initial "integrations" with HV. So back then
the
>>>>> thought-process (not mine, btw) was that yes, that *is* valid -
hence
>>>>> the
>>>>> option to chose just DDL as an option.
>>>>>
>>>>
>>>> You'd still have that ability with my suggestion, just keep
validation
>>>> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>>>>
>>>> By "safest mode" above I meant CALLBACK is the right way if you
really
>>>> want to make sure that lifecycle validation occurs, or you'll get an
>>>> exception if no BV provider is present. It can't happen that
lifecycle
>>>> validation silently, unexpectedly doesn't happen. Hence I prefer it
over
>>>> AUTO. And as things stand I can't benefit from constraints in DDL
export in
>>>> that case, which is a pity.
>>>>
>>>> But if thats now no longer valid then that changes things.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>>>>> guillaume.smet(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>
>>>>> > Hi,
>>>>> >
>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole
<steve(a)hibernate.org>
>>>>> > wrote:
>>>>> >>
>>>>> >> Is it valid for a user to want *just* DDL-based validation?
How
>>>>> would
>>>>> >> that
>>>>> >> work in Gunnar's request?
>>>>> >>
>>>>> >
>>>>> > From your writings, I suspect I'm the only one with this
opinion but
>>>>> my
>>>>> > answer would be: "not if you use Bean Validation
annotations".
>>>>> >
>>>>> > If you use BV's @NotNull, you expect BV to validate the
input. And
>>>>> you
>>>>> > might want additional DDL in your database to be on the safe
side
>>>>> (which
>>>>> > should be the default IMHO).
>>>>> >
>>>>> > --
>>>>> > Guillaume
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>