Re: [hibernate-dev] Fun with DDLWithoutCallbackTest

It seems like you got this "minro db" list based on the overrides of this method. Keep in mind that this list does not seem accurate. It sure seems like postgresql and db2 fall into this category as well unless i am misunderstand the test failure discussion here. Like I said there is another option where we could hoist the check constraints attached to the Column into the table-level check constraint listing for these dialects. Thinking more about it, I guess the change in behavior here is not really such a big compatibility issue. Anyway, if you want me to go that route create a JIRA please and assign to me. On Thu, 2010-06-17 at 16:07 +0200, Emmanuel Bernard wrote: > There are two things at stake here. > > DDLWithoutCallbackTest was initially designed to check that the event listener validation is ignored. Hence the catch (javax.validation.ConstraintViolationException) {fail();} > What I forgot is that the test my still fails due to a database constraint error :) > Steve has fixed that by guarding against dialects not supporting column checks and also tests that a DB failure happens (which is an additional use case this test did not cover). > > Another problem is that the BV integration does push some constraints (min / max atm) as column level check constraints which are not supported by all dialects. We cannot depend on the dialect because all that is set at configuration time and we know the current limitation on that. I'm perfectly happy with the DDL change not being propagated for min/max for these kind of databases (they are minor - HSQLDB, JDataStore, TimesTen). > > Emmanuel > > On 16 juin 2010, at 18:05, Steve Ebersole wrote: > >>> 2.3) There is a general issue with >>> org.hibernate.test.annotations.beanvalidation.DDLWithoutCallbackTest >>> that I pinged you and Emmanuel about before but never heard a response. >>> Basically right now the test is totally geared to hsqldb. It even >>> failed initially on h2. The issue has to do with the >>> getDialect().supportsColumnCheck() protections I added. The issue is a >>> mismatch between how the mapping package handles check constraints and >>> how the validation code is handling them. IIRC the validation code is >>> always adding them to the Column. However the mapping package also >>> accounts for table-level check constraints. However, Table only applies >>> the check contraint at the level it was defined; basically it assumes >>> the code building it will put it in the right place (column level versus >>> tabale level) for the given dialect. So either we need to change the >>> way y'all push the check constraints to be dialect aware, or we need to >>> change the create/alter scripts for table to account for this new >>> requirement (although that of course changes the behavior). > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole <steve(a)hibernate.org&gt; http://hibernate.org