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