Hi, If the JPA validation mode is set to CALLBACK, BV constraints such as @NotNull, @Size etc. are not reflected in the DDL created by ORM. Instead, in TypeSafeActivator, the BV constraints are only considered for DDL if the validation mode is DDL or AUTO [1]. CALLBACK is the safe way to ensure BV is invoked by JPA (instead of silently ignoring it if no BV provider is present), so it's the setting I usually recommend. I think constraints should also be propagated to DDL in this mode, so I'm wondering whether there a specific reason for the current behaviour or wether we can change it? Thanks, --Gunnar [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

The reasoning is that the 2 BV modes you mention make no mention of also applying constraints to the database. It would be surprising for that to happen. I can see the argument for AUTO, but absolutely not for CALLBACK.

Also important is the distinction that hibernate accepts multivalued validation modes, whereas BV does not if I remember correctly... Although in my opinion it absolutely should.

On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris(a)hibernate.org&gt; wrote: > Gunnar - > > I don't particularly see a reason why we cannot as it seems we're > handling the CALLBACK mode with no BV provider present earlier in the > code path. I'm fine changing it. > > Chris > > > On 02/04/2018 07:21 AM, Gunnar Morling wrote: > > Hi, > > > > If the JPA validation mode is set to CALLBACK, BV constraints such as > > @NotNull, @Size etc. are not reflected in the DDL created by ORM. > > > > Instead, in TypeSafeActivator, the BV constraints are only considered > for > > DDL if the validation mode is DDL or AUTO [1]. > > > > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of > > silently ignoring it if no BV provider is present), so it's the setting > I > > usually recommend. I think constraints should also be propagated to DDL > in > > this mode, so I'm wondering whether there a specific reason for the > current > > behaviour or wether we can change it? > > > > Thanks, > > > > --Gunnar > > > > [1] > > https://github.com/hibernate/hibernate-orm/blob/master/ > hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/ > TypeSafeActivator.java#L146 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

I'm not sure I would call them separate. They are clearly linked. Look at it this way, if we export various "validation" constraints to the database (DDL) it is, practically speaking, a performance overhead to also perform those checks in memory. Right? This is, I think, the distinction you may be missing in terms of DDL as a separate mode - only do these checks once, at the database level.

Can all such validations be handled at the database level via contraints? No of course not - but the vast majority in fact can.

On Tue, Feb 6, 2018, 7:52 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> The reasoning is that the 2 BV modes you mention make no mention of also >> applying constraints to the database. It would be surprising for that to >> happen. I can see the argument for AUTO, but absolutely not for CALLBACK. >> > I think that a) "trigger validation upon insert/update" and b) "propagate > constraints to the DDL" are two separate concerns which should be handled > independently. > > I.e. ideally I'd keep the "validation mode" property solely focused on a) > (i.e. not have that DDL enum member) and control b) (which is as you say > not defined by the spec) via a separate property. In fact, ORM already has > a property applying to b), "hibernate.validator.apply_to_ddl", although > it seems linked to "legacy Hibernate Validator" as per a log statement in > TypeSafeActivator ( > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src... > ). > >> Also important is the distinction that hibernate accepts multivalued >> validation modes, whereas BV does not if I remember correctly... Although >> in my opinion it absolutely should. >> > "validation mode" is defined by JPA, not BV. As per above I don't think it > needs to be multi-valued, those two aspects can be handled separately. > > > >> >> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris(a)hibernate.org&gt; wrote: >> >>> Gunnar - >>> >>> I don't particularly see a reason why we cannot as it seems we're >>> handling the CALLBACK mode with no BV provider present earlier in the >>> code path. I'm fine changing it. >>> >>> Chris >>> >>> >>> On 02/04/2018 07:21 AM, Gunnar Morling wrote: >>> > Hi, >>> > >>> > If the JPA validation mode is set to CALLBACK, BV constraints such as >>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM. >>> > >>> > Instead, in TypeSafeActivator, the BV constraints are only considered >>> for >>> > DDL if the validation mode is DDL or AUTO [1]. >>> > >>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of >>> > silently ignoring it if no BV provider is present), so it's the >>> setting I >>> > usually recommend. I think constraints should also be propagated to >>> DDL in >>> > this mode, so I'm wondering whether there a specific reason for the >>> current >>> > behaviour or wether we can change it? >>> > >>> > Thanks, >>> > >>> > --Gunnar >>> > >>> > [1] >>> > >>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src... >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Tue, Feb 6, 2018 at 9:18 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > On 6 February 2018 at 14:46, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > I'm not sure I would call them separate. They are clearly linked. Look > > at > > it this way, if we export various "validation" constraints to the > > database > > (DDL) it is, practically speaking, a performance overhead to also > > perform > > those checks in memory. Right? This is, I think, the distinction you may > > be > > missing in terms of DDL as a separate mode - only do these checks once, > > at > > the database level. > > That's a grey area. Sure they are linked, as some combinations would > be nonsense, but I'd see benefits as well in being able to control > such aspects better. > > In terms of performance, it might be beneficial to abort an operation > early on ("in memory") rather than have to bother the database. It's > far easier to scale a system by adding more JVMs than to scale the > RDBMs. > > True it might be redundant if the business logic is perfect, but then > you'd not need validation. We tend to do this argument where it "not what we would do". Well not everyone is us :)

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.

> > Can all such validations be handled at the database level via > > contraints? > > No of course not - but the vast majority in fact can. > > Back in the days I've found it very useful that Hibernate ORM + > Validator + custom naming strategies, etc.. would allow me to fully > control all details of the DDL. > I used to version the DDL and have a script which gets ORM to dump it > on the same resource for each change on the model, to immediately see > the diff and understand all implications of any change on the model. > Ideal also for beginners to grow confidence in what exactly all those > annotations will do.. Neither what Gunnar is saying nor what we do not preclude that.

All of those are valid options. But I think Gunnar's suggestion misses

All of those are valid options. But I think Gunnar's suggestion misses

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(a)hibernate.org&gt; 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(a)hibernate.org&gt;: > >> On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sanne(a)hibernate.org&gt; >> wrote: >> >>> On 6 February 2018 at 15:34, Steve Ebersole <steve(a)hibernate.org&gt; >>> 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 >> >> >

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

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.

On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > Hi, > > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve(a)hibernate.org&gt; > 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

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&gt; wrote: > 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> 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&gt; >> wrote: >> > >> > Hi, >> > >> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> > 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 >> >

How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?

How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?

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 <gunnar(a)hibernate.org&gt; wrote: > > 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-generator/src/main/xsd/ > persistence_2_1.xsd#L326-L339. > > 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> 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&gt; >> 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&gt;: >>> >>>> 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&gt; >>>> wrote: >>>> >>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>> >>>>>> 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&gt; >>>>>> wrote: >>>>>> >>>>> >>>>>> > Hi, >>>>>> > >>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole < >>>>>> steve(a)hibernate.org&gt; >>>>>> > 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 >>>>>> >>>>> >>> >

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 Sounds great. Exactly what I had in mind :)

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.

Yes, I agree. On Sat, Feb 10, 2018, 7:55 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2018-02-09 16:26 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> 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 >> >> Sounds great. Exactly what I had in mind :) > > >> 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. >> > > Exactly. That's why I recommend users to go with CALLBACK over AUTO. > > WDYT? >> > > Seems we're on the same page. I can do this change, my only question > would be about dropping the DDL enum member and rejecting multiple values > (your 1. and 2. above). Should we first (i.e. in 5.3) deprecate the enum > member and log a warning if multiple values are given? > > >> >> On Fri, Feb 9, 2018 at 9:14 AM Gunnar Morling <gunnar(a)hibernate.org&gt; >> 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 <steve(a)hibernate.org&gt;: >>> >>>> 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 <gunnar(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> > 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-generator/src/main/xsd/ >>>>> persistence_2_1.xsd#L326-L339. >>>>> >>>>> 2018-02-07 20:05 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>> >>>>>> 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&gt; >>>>>> 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&gt;: >>>>>>> >>>>>>>> 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&gt; wrote: >>>>>>>> >>>>>>>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>>>>> >>>>>>>>>> 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&gt; >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>>> > Hi, >>>>>>>>>> > >>>>>>>>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> > 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 >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>

My question essentially is why is it alright to piggy-back the enablement of the DDL constraint export on JPA's validation mode option (which only has been designed with the lifecycle validation in mind) for AUTO but not for CALLBACK?

It causes a few issues: When using CALLBACK (which is the right setting if you really want to make sure that lifecycle validation happens), there's currently no way to have the constraint export to DDL. JPA won't allow me to specify { CALLBACK, DDL } (as it's only a single-valued option as you say). So I'd have to use AUTO, at the risk of lifecycle validation being not enabled silently if the BV provider is missing from the classpath for some reason. Also the interaction with "hibernate.validator.apply_to_ddl" is confusing, as this only can be used to turn off the DDL export of constraints but enabling it (the default) doesn't itself guarantee that this is happening.

2018-02-06 15:46 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I'm not sure I would call them separate. They are clearly linked. Look at > it this way, if we export various "validation" constraints to the database > (DDL) it is, practically speaking, a performance overhead to also perform > those checks in memory. Right? This is, I think, the distinction you may be > missing in terms of DDL as a separate mode - only do these checks once, at > the database level. > > Can all such validations be handled at the database level via contraints? > No of course not - but the vast majority in fact can. > > > > On Tue, Feb 6, 2018, 7:52 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > >> 2018-02-06 14:41 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> The reasoning is that the 2 BV modes you mention make no mention of >>> also applying constraints to the database. It would be surprising for that >>> to happen. I can see the argument for AUTO, but absolutely not for >>> CALLBACK. >>> >> I think that a) "trigger validation upon insert/update" and b) >> "propagate constraints to the DDL" are two separate concerns which should >> be handled independently. >> >> I.e. ideally I'd keep the "validation mode" property solely focused on >> a) (i.e. not have that DDL enum member) and control b) (which is as you say >> not defined by the spec) via a separate property. In fact, ORM already has >> a property applying to b), "hibernate.validator.apply_to_ddl", although >> it seems linked to "legacy Hibernate Validator" as per a log statement in >> TypeSafeActivator ( >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src... >> ). >> >>> Also important is the distinction that hibernate accepts multivalued >>> validation modes, whereas BV does not if I remember correctly... Although >>> in my opinion it absolutely should. >>> >> "validation mode" is defined by JPA, not BV. As per above I don't think >> it needs to be multi-valued, those two aspects can be handled separately. >> >> >> >>> >>> On Tue, Feb 6, 2018, 7:35 AM Chris Cranford <chris(a)hibernate.org&gt; >>> wrote: >>> >>>> Gunnar - >>>> >>>> I don't particularly see a reason why we cannot as it seems we're >>>> handling the CALLBACK mode with no BV provider present earlier in the >>>> code path. I'm fine changing it. >>>> >>>> Chris >>>> >>>> >>>> On 02/04/2018 07:21 AM, Gunnar Morling wrote: >>>> > Hi, >>>> > >>>> > If the JPA validation mode is set to CALLBACK, BV constraints such as >>>> > @NotNull, @Size etc. are not reflected in the DDL created by ORM. >>>> > >>>> > Instead, in TypeSafeActivator, the BV constraints are only >>>> considered for >>>> > DDL if the validation mode is DDL or AUTO [1]. >>>> > >>>> > CALLBACK is the safe way to ensure BV is invoked by JPA (instead of >>>> > silently ignoring it if no BV provider is present), so it's the >>>> setting I >>>> > usually recommend. I think constraints should also be propagated to >>>> DDL in >>>> > this mode, so I'm wondering whether there a specific reason for the >>>> current >>>> > behaviour or wether we can change it? >>>> > >>>> > Thanks, >>>> > >>>> > --Gunnar >>>> > >>>> > [1] >>>> > >>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src... >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>>