Re: CTS 1.3.1 results

Lists: pgsql-jdbc
From: Vadim Nasardinov <vadimn(at)redhat(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: CTS 1.3.1 results
Date: 2004-11-24 20:37:31
Message-ID: 200411241537.31943@vadim.nasardinov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-jdbc

I have run CTS 1.3.1 against CVS HEAD.

Here what I get:

+--------------------------------------------+
| | appclient | ejb | jsp | servlet |
|--------+-----------+------+------+---------|
| PASSED | 810 | 810 | 810 | 810 |
|--------+-----------+------+------+---------|
| FAILED | 387 | 387 | 407 | 407 |
|--------+-----------+------+------+---------|
| TOTAL | 1197 | 1197 | 1217 | 1217 |
+--------------------------------------------+

You can find the complete list of failing tests on this page:
http://people.redhat.com/vadimn/scratch/pgsql-jdbc/logs/2004-11-24/report.html

Links to stack traces are broken. If you care to see the whole thing,
grab this file:
http://people.redhat.com/vadimn/scratch/pgsql-jdbc/logs/2004-11-24/cvs-head.tar.gz

In CTS 1.2.1, each individual test attempts to drop and recreate the
tables it needs. This mode of operation leads to massive failures in
the EJB vehicle, as explained in
http://archives.postgresql.org/pgsql-jdbc/2004-11/msg00119.php

In CTS 1.3.1, all the necessary DDL is run prior to and separately
from the actual tests. See
http://java.sun.com/products/jdbc/jdbctestsuite-1_3_1.html

and grep for "initdb".

CTS 1.3.1 comes with two DDL files: one for Cloudscape and another one
for Oracle. I used the Cloudscape file and had to make the following
substitutions to make the "initdb" script succeeed when run against
PosgtreSQL:

TINYINT --> SMALLINT
LONGINT --> BIGINT
LONG VARCHAR --> TEXT
Long varbinary --> BYTEA

One problem that is common to both CTS 1.2.1 and CTS 1.3.1 is the
current backend's inability to support denormal floating point values.

As I mentioned in
http://archives.postgresql.org/pgsql-jdbc/2004-11/msg00137.php

the following currently fails

| DB1=> create table Real_Tab (MAX_VAL REAL, MIN_VAL REAL,NULL_VAL REAL);
| CREATE TABLE
| DB1=> insert into Real_Tab values(3.4E38,1.4E-45, null);
| ERROR: Bad float4 input format -- underflow

The magic numbers 3.4E38 and 1.4E-45 are java.lang.Float.MAX_FALUE and
java.lang.Float.MIN_VALUE. The backend currently only supports a
narrower (normalized) range:

http://www.postgresql.org/docs/7.4/interactive/datatype.html#DATATYPE-FLOAT

On most platforms, the real type has a range of at least 1E-37 to
1E+37 with a precision of at least 6 decimal digits.

To avoid getting gratuitous "float4 underflow" errors, I also made the
following change:

REAL --> DOUBLE PRECISION

Questions:

Do these numbers look about right?

Should I be using $CTS_HOME/bin/ctssql.ddl.cloudscape or
$CTS_HOME/bin/ctssql.ddl.oracle?

Dave, do you have a script for converting Oracle procedure
definitions into Postgres function definitions?

Thanks,
Vadim


From: Kris Jurka <books(at)ejurka(dot)com>
To: Vadim Nasardinov <vadimn(at)redhat(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: CTS 1.3.1 results
Date: 2004-11-24 22:31:12
Message-ID: Pine.BSO.4.56.0411241724300.32211@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-jdbc

On Wed, 24 Nov 2004, Vadim Nasardinov wrote:

> Dave, do you have a script for converting Oracle procedure
> definitions into Postgres function definitions?
>

This is the version I've used. Starting with the oracle script I
converted all of the functions that only take IN parameters. I think I
may have made some additional datatype changes like the float->double
conversion and date->time/timestamp.

Kris Jurka

Attachment Content-Type Size
ctssql.ddl.postgresql.gz application/octet-stream 5.9 KB

From: Xavier Poinsard <xpoinsard(at)free(dot)fr>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: CTS 1.3.1 results
Date: 2004-11-24 22:45:14
Message-ID: 41A50EFA.7050203@free.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-jdbc

Vadim Nasardinov wrote:
> I have run CTS 1.3.1 against CVS HEAD.
>
> Here what I get:
>
> +--------------------------------------------+
> | | appclient | ejb | jsp | servlet |
> |--------+-----------+------+------+---------|
> | PASSED | 810 | 810 | 810 | 810 |
> |--------+-----------+------+------+---------|
> | FAILED | 387 | 387 | 407 | 407 |
> |--------+-----------+------+------+---------|
> | TOTAL | 1197 | 1197 | 1217 | 1217 |
> +--------------------------------------------+
>
>
> You can find the complete list of failing tests on this page:
> http://people.redhat.com/vadimn/scratch/pgsql-jdbc/logs/2004-11-24/report.html
>
> Links to stack traces are broken. If you care to see the whole thing,
> grab this file:
> http://people.redhat.com/vadimn/scratch/pgsql-jdbc/logs/2004-11-24/cvs-head.tar.gz
>

Some errors are probably linked with a setup problem :

Beginning Test: testNullsAreSortedHigh
********************************************************************************
java.io.FileNotFoundException:
http://localhost:8000/dbMeta1_jsp_vehicle/jsp_vehicle.jsp
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:798)
at com.sun.cts.util.TestUtil.getResponse(TestUtil.java:708)


From: Vadim Nasardinov <vadimn(at)redhat(dot)com>
To: Xavier Poinsard <xpoinsard(at)free(dot)fr>, pgsql-jdbc(at)postgresql(dot)org
Subject: failures in dbMetaClient1 (was: Re: CTS 1.3.1 results)
Date: 2004-11-25 02:34:05
Message-ID: 200411242134.05088@vadim.nasardinov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-jdbc

On Wednesday 24 November 2004 17:45, Xavier Poinsard wrote:
> > http://people.redhat.com/vadimn/scratch/pgsql-jdbc/logs/2004-11-24/cvs-head.tar.gz
>
> Some errors are probably linked with a setup problem :
>
> Beginning Test: testNullsAreSortedHigh
> ********************************************************************************
> java.io.FileNotFoundException:
> http://localhost:8000/dbMeta1_jsp_vehicle/jsp_vehicle.jsp
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:798)

Yes, there are 20 of those. You'll find them in the "jsp" and "servlet"
vehicles. These account for the discrepancy between 387 failures in
the appclient/ejb vehicles on the one hand and 407 failures in the
jsp/servlet vehicle on the other hand. All of these are in the
dbMetaClient1 suite of tests and all of them fail in the same manner.

I didn't have a chance to look into this deeply. Any pointers would
be appreciated.

Vadim