Updates to ADBA and AoJ

[Frédéric Montariol]

Douglas,

Thanks a lot for the improvements ! Particularly for Reactive Stream
support and the Exemples class.

I have integrated the changes in my github adba-mirror, see
*https://github.com/pull-vert/adba-mirror
<https://github.com/pull-vert/adba-mirror>*

It can be used from gradle projets, for those who want to play with ADBA
API (dependency includes source code) :

repositories {
    maven { setUrl("https://dl.bintray.com/pull-vert/adba/") }
}

dependencies {
    compile('jdk.incubator:adba:0.05')
}

Thanks for keeping improving this great SQL async API !

Fred


Le jeu. 21 juin 2018 à 20:44, Douglas Surber <douglas.surber at oracle.com> a
écrit :

> 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
>
>