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 18:13:34 GMT


Thomas Dudziak wrote:
> On 1/4/06, Martin van den Bemt <mllist@mvdb.net> wrote:
> 
> 
>>4.1.13 on windows 2000. Default install. After I hit the problem I tried fiddling
with the
>>lower_case_table_names setting and 2 gave some reasonable results, but if you do a
rerun of the
>>tests a couple of times, it is not that predictable anymore...
> 
> 
> MySql is a stupid database in any case. But anyway...
> I think we can safely change the tests to use lowercase table and
> column names anyways. It won't matter semantically for the other

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 :)

> databases: in delimited mode they are supposed to use the name as-is,
> and in undelimited mode they have to convert them to uppercase anyway.
> So in both cases we should not run into any problems.
> And after all its not about testing the databases but rather testing
> DdlUtils handling. E.g. I changed the datatypes tests to not hit any
> boundaries in PostgreSql which are somewhat different from the Java
> type ones.

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).

> 
> 
>>The tests are with delimited table names. Maybe just changing that could do the trick,
but we also
>>want something working with delimeters I guess :)
>>Maybe you missed this link about the case sensitivity :
>>http://dev.mysql.com/doc/refman/4.1/en/name-case-sensitivity.html (added that in MysqlModelReader).
>>But I guess we will end up trying to work around these problems, since mysql is used
pretty much, or
>>maybe we should state on the website to use lowercase tablenames to be on the safe
site or even
>>maybe add a setting to not quote any tablenames.
>>Btw if I create a table in mysql administrator in capitals (on anaother mysql instance,
on windows
>>XP, default install), it will create the table with lowercase names.
> 
> 
> The problem is the stupid mapping to filenames that MySql does for
> table names. Shouldn't be too hard for them to add a map table name ->
> filename, shouldn't it ? But I digress ...

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 can have a quick look at it tomorrow or in the next like 20 minutes
>>>if you want ?
>>
>>A sanity check would be nice..  I'll focus on the Datatypes and a double roundtrip,
since
>>roundtripping doesn't cover everything (eg the stuff that I wrote on the wiki about
automatic
>>conversion of VARCHAR 1024 to TEXT, which when reading back from mysql returns a LONGVARCHAR
type,
>>which ends up in mysql again as MEDIUMTEXT, you get the drift).
> 
> 
> That's what the third argument in the addNativeTypeMapping is for.
> E.g. for PostgreSql:
> 
> info.addNativeTypeMapping(Types.ARRAY, "BYTEA", Types.BINARY);
> 
> means that Types.ARRAY will be mapped to PostgreSql's type BYTEA which
> when read back via the JdbcModelReader, will result in a Types.BINARY
> column.
> This is for the ALTER TABLE stuff which otherwise would always try to
> change the column type.

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.

Enough complaining :)


Mvgr,
Martin

> 
> Tom
> 
> 

Mime
View raw message