Thomas Dudziak wrote:
On 1/4/06, Martin van den Bemt <[EMAIL PROTECTED]> 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
