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
