Обсуждение: CTS 1.3.1 results

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

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

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)

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