Re: [hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK
Ok, so the constraints would be added to DDL when "hibernate
.validator.apply_to_ddl" is true and validation mode is one of {AUTO,
CALLBACK, DDL}. And they wouldn't be added to the DDL if "hibernate
.validator.apply_to_ddl" is false or validation mode is NONE?
That'd work for me.
2018-02-07 21:07 GMT+01:00 Steve Ebersole :
> No, I think you are right and `hibernate.validator.apply_to_ddl` should
> apply to CALLBACK as well.
>
> On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling
> wrote:
>
>> > How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>
>> I was referring to the dedicated 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 but not that string property).
>>
>> [1] https://github.com/hibernate/hibernate-orm/blob/
>> master/tooling/metamodel-generator/src/main/xsd/
>> persistence_2_1.xsd#L326-L339.
>>
>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole :
>>
>>> 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
>>> wrote:
>>>
Right, giving multiple values isn't allowed as per JPA's XSD.
2018-02-07 19:44 GMT+01:00 Steve Ebersole :
> 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
> wrote:
>
>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole :
>>
>>> 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.s...@gmail.com>
>>> wrote:
>>>
>>
>>> > Hi,
>>> >
>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <
>>> st...@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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK
I think constraints should be exported to the DDL when the mode is DDL or `
hibernate.validator.apply_to_ddl == true`. I'd personally say that `
hibernate.validator.apply_to_ddl` still works with NONE - as y'all keep
saying, mode is about in-memory callbacks. In fact because of that, we
should even consider:
1. droping DDL as an allowable mode
2. no longer allowing multiple values
Additionally I'd say that AUTO maps to CALLBACK *as long as BV is available
on the classpath. As I understand it, using CALLBACK mode is supposed to
cause an error when BV is not available on classpath. AUTO would silently
ignore that.
WDYT?
On Fri, Feb 9, 2018 at 9:14 AM Gunnar Morling wrote:
> Ok, so the constraints would be added to DDL when "hibernate
> .validator.apply_to_ddl" is true and validation mode is one of {AUTO,
> CALLBACK, DDL}. And they wouldn't be added to the DDL if "hibernate
> .validator.apply_to_ddl" is false or validation mode is NONE?
>
> That'd work for me.
>
> 2018-02-07 21:07 GMT+01:00 Steve Ebersole :
>
>> No, I think you are right and `hibernate.validator.apply_to_ddl` should
>> apply to CALLBACK as well.
>>
>> On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling
>> wrote:
>>
>>> > How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>>
>>> I was referring to the dedicated 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 but not that string property).
>>>
>>> [1]
>>> https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-generator/src/main/xsd/persistence_2_1.xsd#L326-L339
>>> .
>>>
>>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole :
>>>
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
wrote:
> Right, giving multiple values isn't allowed as per JPA's XSD.
>
> 2018-02-07 19:44 GMT+01:00 Steve Ebersole :
>
>> 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
>> wrote:
>>
>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole :
>>>
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.s...@gmail.com>
wrote:
>>>
> Hi,
>
> On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <
st...@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
Re: [hibernate-dev] Jenkins updates tomorrow
I finished the Jenkins upgrades, I'm working on fixing some CSS issues. If you have some problems with the Jobs, let me know. Cheers, Davide On Thu, Feb 8, 2018 at 3:48 PM, Guillaume Smet wrote: > Thanks for warning and thanks for doing the update! > > > On Thu, Feb 8, 2018 at 4:34 PM, Davide D'Alto wrote: >> >> Hi, >> I'm planning to update Jenkins tomorrow, it should painless but, just in >> case, >> expect possible disruptions. >> >> Cheers, >> Davide > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Jenkins updates tomorrow
CSS should be fixed as well now. There was a problem when going to the Nodes page where the buttons overlapped with the logout link. Let me know if there is something else weird. Cheers, Davide On Fri, Feb 9, 2018 at 7:23 PM, Davide D'Alto wrote: > I finished the Jenkins upgrades, I'm working on fixing some CSS issues. > > If you have some problems with the Jobs, let me know. > > Cheers, > Davide > > On Thu, Feb 8, 2018 at 3:48 PM, Guillaume Smet > wrote: >> Thanks for warning and thanks for doing the update! >> >> >> On Thu, Feb 8, 2018 at 4:34 PM, Davide D'Alto wrote: >>> >>> Hi, >>> I'm planning to update Jenkins tomorrow, it should painless but, just in >>> case, >>> expect possible disruptions. >>> >>> Cheers, >>> Davide >> >> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
