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>
http://hibernate.org