db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Date Wed, 04 Jan 2006 22:05:32 GMT
On 1/4/06, Martin van den Bemt <mllist@mvdb.net> wrote:

> If you are not busy with this, let me know, I'll start on it right away, else we both
are doing the
> same thing.

Already done and tested against Hsqldb, PostgreSql, Derby and McKoi :-)

> I'll explain a little better (and fix the mistakes :):
> - I define a column with VARCHAR 1024 in my model.
> - The column is created and returns a mysql native type of TEXT
> - The old model and new model are therefore not equal to eachother.
> To make it worse when roundtripping again :
> So you end up with a mediumtext if you roundtrip twice..
> Either way : I have absolutely no way of knowing that the original definition of TEXT
> 1024. The real bad part is (at least for users) that a VARCHAR behaves differently than
> About the same story goes for the BIT type (with conversion TINYINT(1)). Was TINYINT(1)
> configured as BIT or as TINYINT(1) ?

The tests as they are now are intended to prove the following:

* DdlUtils setups the database so that the limits as set by the JDBC
spec are honored
  In particular this means that
  - you can use the Java type corresponding to the JDBC type for
inserting and retrieving data
  - (within limits) you can use the full range of the JDBC type(where
    e.g. for CHAR/VARCHAR JDBC states that a database should (no
requirement though) at least support 254 characters

Now, at this point, I've added the back mapping here for two reasons

- to make the tests simpler: I can simply compare the original model
with an adapted model where the column datatypes are changed to the
datatypes specified by the back mapping
- to provide a foundation for the ALTER TABLE handling (I believe
there are bugs in JIRA regarding this)

By no means are the tests intended to test this ALTER TABLE handling
though. Rather, we need specific tests.

The interesting question now is: does MySql map VARCHAR(128) and
VARCHAR(1024) differently, e.g. to VARCHAR vs. MEDIUMTEXT ? If yes, I
still do not consider this a problem. After all, JDBC only asks the
database to support VARCHAR of up to 254 length. If sizes above that
finally map to LONGVARCHAR then that is ok to me. In fact, it might
have been useful to define the column as LONGVARCHAR in the first

> So it will be nearly impossible to do a full roundtrip of the model. A better shot probably
> roundtripping the DDL itself.
> So read model and load model, generate DDL for both and compare the result of the generated
> (this is  what I do at a private project of mine, to see if the db needs updating btw)

This might be useful for tests for the database alteration
functionality (which IMO we still have to provide though perhaps not
for the 1.0).

> If you hold off removing the mysql package for now, I will create the test with DDL comparing
> on the default testcases.. And see if that will do the trick.

If you want to add tests for the database alteration, please go ahead.
But for the datatypes/constraints tests I would prefer if we let them
as they are. IMO they do what they are supposed to do (though perhaps
not more as you've shown).

If you don't mind, then I'll finish the MySql platform (add the back
mapping to the addNativeTypeMapping registrations) ?


View raw message