You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ddlutils-dev@db.apache.org by mv...@apache.org on 2006/01/03 20:53:02 UTC
svn commit: r365722 -
/db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Author: mvdb
Date: Tue Jan 3 11:52:59 2006
New Revision: 365722
URL: http://svn.apache.org/viewcvs?rev=365722&view=rev
Log:
Make test fail when the platform doesn't match. Else we have a bogus passing test.
Modified:
db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Modified: db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
URL: http://svn.apache.org/viewcvs/db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java?rev=365722&r1=365721&r2=365722&view=diff
==============================================================================
--- db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java (original)
+++ db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java Tue Jan 3 11:52:59 2006
@@ -186,6 +186,10 @@
assertEquals(getAdjustedModel(),
getPlatform().readModelFromDatabase("roundtriptest"));
}
+ else
+ {
+ fail("Platform " + getPlatformName() + " does not match " + getPlatform().getName());
+ }
}
/**
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
Thanx.. Upgrading the driver to 3.1 did the trick (was still on 3.0)..
Mvgr,
Martin
Thomas Dudziak wrote:
> On 1/5/06, Martin van den Bemt <ml...@mvdb.net> wrote:
>
>>No errors on the constaint tests, but still 7 failures and 2 errors on the datatypes test..
>>So don't know what's wrong if that works for you...
>
>
> Mhm, this is my setup:
>
> Windows XP SP2
> Java 5
> MySql 4.1.16 (Windows Essentials Version)
> MySql Connector/J 3.1.12
>
> I would think it has to do with the JDBC driver, could you try the 3.1
> driver (unless you're already doing so) ?
>
> Tom
>
>
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/5/06, Martin van den Bemt <ml...@mvdb.net> wrote:
> No errors on the constaint tests, but still 7 failures and 2 errors on the datatypes test..
> So don't know what's wrong if that works for you...
Mhm, this is my setup:
Windows XP SP2
Java 5
MySql 4.1.16 (Windows Essentials Version)
MySql Connector/J 3.1.12
I would think it has to do with the JDBC driver, could you try the 3.1
driver (unless you're already doing so) ?
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
No errors on the constaint tests, but still 7 failures and 2 errors on the datatypes test..
So don't know what's wrong if that works for you...
Eg on the testBitWithDefault :
<database name="roundtriptest">
<table name="roundtrip">
<column name="pk" primaryKey="true" required="true" type="INTEGER" default="0"
autoIncrement="false"/>
<column name="value" primaryKey="false" required="true" type="BIT" default="FALSE"
autoIncrement="false"/>
</table>
</database>
Actual model:
<database name="roundtriptest">
<table name="roundtrip">
<column name="pk" primaryKey="true" required="true" type="INTEGER" size="11" default="0"
autoIncrement="false"/>
<column name="value" primaryKey="false" required="true" type="TINYINT" size="1" default="0"
autoIncrement="false"/>
</table>
</database>
Mvgr,
Martin
Thomas Dudziak wrote:
> On 1/4/06, Martin van den Bemt <ml...@mvdb.net> wrote:
>
>
>>No problem. Curious how much you can get running (currently have 18 failures and 3 errors) on the
>>datatypestest.
>
>
> MySql should work now, at least locally all 53 tests pass for me.
>
> regards,
> Tom
>
>
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/4/06, Martin van den Bemt <ml...@mvdb.net> wrote:
> No problem. Curious how much you can get running (currently have 18 failures and 3 errors) on the
> datatypestest.
MySql should work now, at least locally all 53 tests pass for me.
regards,
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/4/06, Martin van den Bemt <ml...@mvdb.net> wrote:
> > 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).
>
> This is the part I am very interested in and using most of the time actually :)
To expand on that a bit more:
I think we need (at least for after the 1.0) two more sets of tests:
(1) Database alteration.
Similar to the datatype/constraint tests, we start with a model and
create it in the database. Then we change the original model in one
aspect, e.g. add a column, or change the size of a column or whatever.
Then we ask the platform to alter the database and check what happens.
To make the tests database independent, it is probably useful to
compare the model read-back after the initial creation - adjusted
according to the intentioned change - with the model read-back after
the alteration. Or we could check the alteration SQL, though then the
tests are database specific.
(2) Reading and using of live databases.
Here we should create the database using database-specific SQL (e.g. a
test per native type as well as the constraints, default values etc.),
then read it back, check this model and perhaps also insert some stuff
and get it back (as the datatype tests do).
But honestly, I think we should do this after the 1.0 because this
looks like a lot of work ...
> No problem. Curious how much you can get running (currently have 18 failures and 3 errors) on the
> datatypestest.
I just discovered that MySql returns a default value for columns
specified as not null, even if there was no default value spec.
Strange database ...
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
Thomas Dudziak wrote:
> On 1/4/06, Martin van den Bemt <ml...@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 :-)
>
Just noticed it :)
> - 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
> place.
I didn't have the jdbc spec in mind. Just checked the docs of mysql and 255 (in 3.2 254) is the max
size. My bad here :)
>
>
>>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)
>
>
> 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).
This is the part I am very interested in and using most of the time actually :)
>
>
>>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.
>
>
> 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).
Agreed on that, it was not my intention to zap them :)
>
> If you don't mind, then I'll finish the MySql platform (add the back
> mapping to the addNativeTypeMapping registrations) ?
No problem. Curious how much you can get running (currently have 18 failures and 3 errors) on the
datatypestest.
I'll take an early nap today I think.. I will have a go at the ddl stuff tomorrow..
Mvgr,
Martin
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/4/06, Martin van den Bemt <ml...@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
> - 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) ?
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
specified);
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
place.
> 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)
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 based
> 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) ?
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
Thomas Dudziak wrote:
> On 1/4/06, Martin van den Bemt <ml...@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
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/4/06, Martin van den Bemt <ml...@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 :-)
> 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).
> 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.
> 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.
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
Thomas Dudziak wrote:
> On 1/4/06, Martin van den Bemt <ml...@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
>
>
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/4/06, Martin van den Bemt <ml...@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
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.
> 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 ...
> > 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.
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
Thomas Dudziak wrote:
> On 1/4/06, Martin van den Bemt <ml...@mvdb.net> wrote:
>
>>If you don't mind : I am adding mysql anyway for now, since it almost needs lots of extensionsof the
>>xml models (lot's of issues with equals on table names).
>>I would appreciate it, if you don't touch these classes tonight or tomorrow during the day, since I
>>really need working mysql integration at work tomorrow.
>
>
> What version of MySql are you using ?
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...
>
>
>>If you have better ideas with this mysql shite, I like to hear it :).
>>One solution could be to make all table names lowercase in the tests, but that will probably
>>conflict with a database that only supports uppercase tablenames..
>>The commits will contain links to the mysql documents that talk about this issue.
>
>
> Actually, I think one of the SQL standards *requires* the databases to
> convert table names to uppercase in undelimited mode (and to use them
> as-is in delimited mode), so I think the problem lies elsewhere.
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.
>
> 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).
Mvgr,
Martin
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/4/06, Martin van den Bemt <ml...@mvdb.net> wrote:
> If you don't mind : I am adding mysql anyway for now, since it almost needs lots of extensionsof the
> xml models (lot's of issues with equals on table names).
> I would appreciate it, if you don't touch these classes tonight or tomorrow during the day, since I
> really need working mysql integration at work tomorrow.
What version of MySql are you using ?
> If you have better ideas with this mysql shite, I like to hear it :).
> One solution could be to make all table names lowercase in the tests, but that will probably
> conflict with a database that only supports uppercase tablenames..
> The commits will contain links to the mysql documents that talk about this issue.
Actually, I think one of the SQL standards *requires* the databases to
convert table names to uppercase in undelimited mode (and to use them
as-is in delimited mode), so I think the problem lies elsewhere.
I can have a quick look at it tomorrow or in the next like 20 minutes
if you want ?
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
If you don't mind : I am adding mysql anyway for now, since it almost needs lots of extensionsof the
xml models (lot's of issues with equals on table names).
I would appreciate it, if you don't touch these classes tonight or tomorrow during the day, since I
really need working mysql integration at work tomorrow.
If you have better ideas with this mysql shite, I like to hear it :).
One solution could be to make all table names lowercase in the tests, but that will probably
conflict with a database that only supports uppercase tablenames..
The commits will contain links to the mysql documents that talk about this issue.
Mvgr,
Martin
Thomas Dudziak wrote:
> On 1/3/06, Martin van den Bemt <ml...@mvdb.net> wrote:
>
>
>>I hit the issue when setting the wrong property on the running test (the mysql profile on the
>>postgresql test in this case).
>>I've added a property to have it fail.
>
>
> After some thinking I realized that database-specific sub packages of
> the io test package are not even necessary right now, because I don't
> think that for any database a test method has to be redefined (instead
> a change to the platform or a new flag for the platform info will be
> necessary in such a case as I have done for Mckoi which does not
> support non-unique indices).
> Therefore, I've removed these sub packages and changed the
> constraints and datatypes test classes so that they can be executed
> directly. So only two test classes remain with together 53 tests
> (executed per database).
>
> This also means that this property is no longer necessary because
> there ain't any tests for a different database anymore. Sorry for the
> confusion that the sub packages caused :-)
>
> As I said, I'll modify these test classes once I have the time, so
> that the tests are executed twice (in delimited and in undelimited
> identifier mode) for databases that support this (-> new flag, true
> for all dbs except Axion).
>
> regards,
> Tom
>
>
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/3/06, Martin van den Bemt <ml...@mvdb.net> wrote:
> I hit the issue when setting the wrong property on the running test (the mysql profile on the
> postgresql test in this case).
> I've added a property to have it fail.
After some thinking I realized that database-specific sub packages of
the io test package are not even necessary right now, because I don't
think that for any database a test method has to be redefined (instead
a change to the platform or a new flag for the platform info will be
necessary in such a case as I have done for Mckoi which does not
support non-unique indices).
Therefore, I've removed these sub packages and changed the
constraints and datatypes test classes so that they can be executed
directly. So only two test classes remain with together 53 tests
(executed per database).
This also means that this property is no longer necessary because
there ain't any tests for a different database anymore. Sorry for the
confusion that the sub packages caused :-)
As I said, I'll modify these test classes once I have the time, so
that the tests are executed twice (in delimited and in undelimited
identifier mode) for databases that support this (-> new flag, true
for all dbs except Axion).
regards,
Tom
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Martin van den Bemt <ml...@mvdb.net>.
I hit the issue when setting the wrong property on the running test (the mysql profile on the
postgresql test in this case).
I've added a property to have it fail.
Mvgr,
Martin
Thomas Dudziak wrote:
> On 1/3/06, mvdb@apache.org <mv...@apache.org> wrote:
>
>
>>Make test fail when the platform doesn't match. Else we have a bogus passing test.
>
>
> Please don't do that! Before this change, I could simply run all tests
> in src/test package (e.g. in Eclipse "run all tests in package")
> regardless of which database I run against. This is no longer possible
> if the wrong platform fails the test.
>
> Btw, I have some ideas to make this a lot nicer using parameterized
> tests (so that we do not need the test cases per platform anymore),
> but I won't have time for it before the weekend.
>
> regards,
> Tom
>
>
Re: svn commit: r365722 - /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/3/06, mvdb@apache.org <mv...@apache.org> wrote:
> Make test fail when the platform doesn't match. Else we have a bogus passing test.
Please don't do that! Before this change, I could simply run all tests
in src/test package (e.g. in Eclipse "run all tests in package")
regardless of which database I run against. This is no longer possible
if the wrong platform fails the test.
Btw, I have some ideas to make this a lot nicer using parameterized
tests (so that we do not need the test cases per platform anymore),
but I won't have time for it before the weekend.
regards,
Tom