db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin van den Bemt <mll...@mvdb.net>
Subject Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Date Wed, 04 Jan 2006 21:41:49 GMT


Thomas Dudziak wrote:
> On 1/4/06, Martin van den Bemt <mllist@mvdb.net> wrote:
> 
> 
>>Column names in delimited mode works correctly in mysql. I think axion had the same
kind of
>>semantics with a difference in behaviour in delimiting tables and column names (although
I am not
>>sure anymore these days :)
> 
> 
> But I think we can change that nonetheless, so we don't need the
> Mysql-specific test cases anymore. I'll do that later on unless you
> beat me to it :-)

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.

> 
> 
>>Hitting boundaries is pretty simple indeed and testing the database a bit is quite
inevitable (hope
>>that is english:) if you consider some user scenario's. (eg difference in behaviour
of MyISAM and
>>innoDB).
> 
> 
> IMO we should change the tests then, because as I said, we do not test
> the database (and we make no assumptions as to whether the values
> specified by a user e.g. for a default value, is valid for a given
> database).

Good point..

> 
> 
>>It worked a lot better in 3.x, see complaints in comment of the link I send :)
>>Hope 5 does a better job, but I will test on that first with the new base tests you
created last night.
> 
> 
> I would not be suprised if we have to create three platforms, for
> MySql 3, 4, and 5.

That's why I named the test already with 41 in there :)

> 
> 
>>Sweet.. I'll have a look at that and see if it solves (part) of the problem..
>>In any case roundtripping a VARCHAR of 1024 is going to be tedious, since I have no
way of knowing
>>what the original definition was. The only thing I know from eg MEDIUMTEXT resulting
from the
>>VARCHAR 1024 is that the size specified in the VARCHAR is at least xxxx (couldn't
find a reference
>>yet..). Afaik Oracle just accepts a VARCHAR of 1024 without messing with your type.
> 
> 
> The relevant thing is what the JDBC driver returns because it has to
> convert this to a JDBC type. Use the DumpMetadataTask for checking
> what the JDBC metadata for a given database is.

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
- TEXT maps to LONGVARCHAR
- The old model and new model are therefore not equal to eachother.
To make it worse when roundtripping again :
- LONGVARCHAR maps to MEDIUMTEXT
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 was
VARCHAR 
1024. The real bad part is (at least for users) that a VARCHAR behaves differently than a
TEXT.

About the same story goes for the BIT type (with conversion TINYINT(1)). Was TINYINT(1) originally

configured as BIT or as TINYINT(1) ?

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

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

Any objections / other ideas ?


Mvgr,
Martin

Mime
View raw message