Updates to ADBA and AoJ

Mark Rotteveel mark at lawinegevaar.nl
Thu Jun 21 17:28:13 UTC 2018


On 21-6-2018 16:59, Douglas Surber wrote:
ADBA changes

For SqlRef the changes removed some of the javadoc, for example

- * @param <T> the type of SQL REF
+ * @param <T>

-   * @return the fully-qualified SQL name of the referenced SQL 
structured type
+   * @return


-	   * @param value an Object representing the SQL structured type instance
-	   * that this Ref object will reference
+	   * @param value

For SqlType the description was changed from

"""
An object that is used to identify a generic SQL type, called a JDBC 
type or a vendor specific data type.
"""

to

"""
Remove dependence on java.sql.
"""

and the javadoc of the various methods have been cleared

> AoJ
> 
>   https://orahub.oraclecorp.com/ora-jdbc-dev/adba-development

Some comments on AoJ while I'm going over the changes:

In `CountOperation.RowCount ` wouldn't it be better to change to

     private long count = -1;

to

     private final long count;

In `OperationGroup`

Intended type of field `submission` is unclear, as both ADBA and AoJ 
have a `Submission` type (based on the imports, it is 
`jdk.incubator.sql2.Submission`).

I would strongly suggest that either the AoJ Submission (and others with 
duplicate names) get renamed, or that an explicit choice gets made to 
either always use the FQN of the ADBA classes (or always the AoJ 
classes, but I think that is less desirable).

Similar for the change of

  public jdk.incubator.sql2.Submission<T> submitHoldingForMoreMembers()

to

  public Submission<T> submitHoldingForMoreMembers()

and for

  public Submission<T> submit()
  Submission<S> submit(Operation<S> op)

In `RowOperation.RowColumn`

Why the assignment of 'default' values, when the constructor overwrites 
them anyway?

About the tests in general:

The existing tests don't actually test anything (or at least: things 
that should lead to failure just pass). They even 'pass' if you don't 
have the driver, the database does not exist, etc.

I'm currently working on rewriting the test for asyncjdbc, and I ran 
into a infinite loop in the code when I actually used a database as 
assumptions where made about the JDBC fetch size return value that don't 
hold for - for example - H2 database (see 
https://gitlab.com/mrotteveel/asyncjdbc/commit/a880f82a9c1c1d8e0be3495a6b7ea50e21ba9094 
)

Mark

-- 
Mark Rotteveel


More information about the jdbc-spec-discuss mailing list