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 <gun...@hibernate.org> wrote: > 2018-02-06 14:41 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > >> 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/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L141 > ). > >> 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 <ch...@hibernate.org> 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@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 >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
