Updates to ADBA and AoJ
Douglas Surber
douglas.surber at oracle.com
Thu Jun 21 18:44:16 UTC 2018
Mark,
I’m not entirely sure what happened with SqlRef. I think I deleted it at one point and I probably did not revert the deletion correctly. I’ll put it top of the list for JavaDoc.
For AoJ I agree about the types referenced. My intent is that all the types referenced are the ADBA types unless there is a specific need to reference an AoJ type. What happened in practice is that NetBeans did whatever and if it compiled I was happy. AoJ is *not* an engineered product. It’s at best the first draft of a proof of concept. By all means make whatever changes to AoJ you think appropriate. I had no goal other than to get the most basic stuff to work at all, just enough to be able to show that it was possible to write code that actually did something. I will continue to update it to reflect any changes to ADBA, but beyond that, no plans. If asyncjdbc.org takes off I might be able to contribute change sets for ADBA changes directly.
I would very much like asyncjdbc.org to succeed. I’m always happy to discuss what AoJ should do and how it might do it. I (and others within Oracle) may contribute code on occasion. We will do anything we can to help the project.
I greatly appreciate everything you (and Dave) have done so far.
Douglas
> On Jun 21, 2018, at 10:28 AM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:
>
> 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