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