Mailing-List: contact ddlutils-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ddlutils-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: domain of tomdzk@gmail.com designates
 64.233.182.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=o6OHD0eNFIK080m8ldUkR6LK+WCBR9e5DEezkQxEpmPp8cJV8ii3Pn/Zl++MFWAIRt2uGBRdWqLWU1DyTzH46i/yQMBWCKoFngi0+037Vgb6ouXJC2+56iliOI6dvPT6vUyYcESqKxrKuwQOlRZ6omZoH1sgnSSgkmcWuAQ6kmg=
Message-ID: <224f32340601041024p60319312r7492b0a6cee74f68@mail.gmail.com>
Date: Wed, 4 Jan 2006 19:24:35 +0100
From: Thomas Dudziak <tomdzk@gmail.com>
To: ddlutils-dev@db.apache.org
Subject: Re: svn commit: r365722 -
 /db/ddlutils/trunk/src/test/org/apache/ddlutils/io/ConstraintsTestBase.java
In-Reply-To: <43BC104E.7090109@mvdb.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20060103195302.45696.qmail@minotaur.apache.org>
	 <224f32340601031203g29baf52egcd8dfa5539c96117@mail.gmail.com>
	 <43BAE7CE.9060806@mvdb.net>
	 <224f32340601031449n7f8ba2b6o312b2b790909fe93@mail.gmail.com>
	 <43BB0FDE.4060609@mvdb.net>
	 <224f32340601031605w194eb352w88a23e5f6d21b69f@mail.gmail.com>
	 <43BC06EF.3020102@mvdb.net>
	 <224f32340601040949x6298fecdjad2019bcdb65d3e1@mail.gmail.com>
	 <43BC104E.7090109@mvdb.net>

On 1/4/06, Martin van den Bemt <mllist@mvdb.net> wrote:

> Column names in delimited mode works correctly in mysql. I think axion ha=
d 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 se=
nd :)
> 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 probl=
em..
> 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 MEDIUMTEX=
T 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