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 <gun...@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 <st...@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 <gun...@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 <st...@hibernate.org>: >>> >>>> On Tue, Feb 6, 2018 at 9:43 AM Sanne Grinovero <sa...@hibernate.org> >>>> wrote: >>>> >>>>> On 6 February 2018 at 15:34, Steve Ebersole <st...@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 >>>> >>>> >>> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
