Flow.Publisher<Void>

[Jens Schauder]

Hi,

I can relate to the wish of having both/multiple options of how to use an
API and that choice should be available to the end user.
The question I have though is: Is this the task of ADBA?
I think it should offer a complete but minimal API allowing third parties
to offer a broad choice of layers on top of that.

Just as it is with JDBC today.
Hardly anybody uses JDBC directly.
Instead people use libraries to abstract away the details they don't want
to care about, with a wide range of options, ranging from

Spring JdbcTemplate, to jOOQ or JPA or even combinations of those.

The same will happen if ADBA offers a complete minimal API to build on.
And that minimal API seems to be RS since you can fairly easily and
efficiently create a CompletionStage from an RS but not the other way round.

Also, this would remove the complexity that emerges from people using both
APIs in parallel.

So, my vote is on a pure reactive API all the way through.

Jens


On Sun, Jul 29, 2018 at 12:27 PM Frédéric Montariol <
frederic.montariol at gmail.com> wrote:

> Hi,
> I really enjoy using Reactive Stream, mostly with Spring 5.X, with a whole
> Reactive Programming model.
> For other needs, I still continue to use Imperative Programming. Most of
> users code this way and don't know Reactive Programming.
>
> I like current ADBA as it gives the choice to the user, who can use
> RowOperation to return a CompletionStage with the result, or choose
> RowPublisherOperation to return result(s) as a Publisher. The user can
> choose a RowPublisherOperation even for a single result if he/she needs a
> Publisher.
>
> ADBA is meant to be the official and unique Async alternative to JDBC in
> the JDK, I would like it to offer various choices.
>
> I am not a big fan of RS in DSL itself, for example subscribe to DataSource
> for getting a Session is not very intuitive for me, I prefer the current
> try with resource approach.
>
> @Douglas :
> You can keep ParameterizedOperation.set(String, CompletionStage, SqlType)
> and add a new method set(String, Publisher, SqlType)
>
> Regards,
> Fred
>
> Le sam. 28 juil. 2018 à 19:53, Stephane Maldini <
> stephane.maldini at gmail.com>
> a écrit :
>
> > IMHO, face to face discussions will always beat ML arguments. Anyhow
> from a
> > Spring perspective it makes sense, this is the route Spring Data has
> > taken  (on
> > top of couchbase, cassandra, mongo etc)  plus some DB drivers such as
> > Lettuce (Redis), R2DBC (Postgres). Beyond data, we find the same patterns
> > in everything Rx, Reactor or Spring (mvc, webflux, security, boot, ...),
> I
> > think Viktor K was also arguing in favor of this previously in the ML and
> > it seems Doug Lea was envisioning something similar when we started the
> RS
> > spec. We might only represent a small voice of the JVM community but
> still
> > an actively interested audience, and I would love to see more of
> > Flow.Publisher use by the JDK itself.
> >
> > For the technical reasons, I find quite a few benefits in a Publisher
> based
> > API :
> > - direct composition via the various reactive library implementors
> > - deferred execution, which is the point of Publisher in general: leave
> the
> > state/payload alone until a consumer is ready
> > - Publisher<Void> has little implementation overhead since there is no
> > request/onNext dance. It still fully respects/represents the intent of
> the
> > reactive-streams specification: onSubscribe, onNext*,
> (onComplete|onError)?
> > in a typed fashion (<Void>).
> > - isolated, repeatable actions since everything happens on subscribe.
> > Implementations have the choice to defer state creation and isolate it
> per
> > subscription, no extra thread coordination required.
> >
> > Eventually the JDK could consider a default toCompletionStage() on
> > Flow.Publisher for convenience when no reactive lib is used. Also in the
> > future with Project Loom, there might be some interest for an Async
> > Iterable as well. Both of those are easy to build from Flow.Publisher,
> > since the decision to start a task is properly isolated and deferred.
> >
> > A few years ago a couple reactive-streams contributors were in favor of
> > adding a specialized Publisher contract to define empty or single
> > emissions, but the simplicity of 3+1 contracts was just too appealing to
> > add a special case Publisher. In Reactor and Rx we still value the
> > cardinality differentiation without relying on CompletionStage for the
> > reasons stated above but I don't see it as a blocker for an audience of
> > implementors like ADBA will have. Yes for a single emission like
> > Publisher<Session> we might have to do a request(1) or request(Long.MAX)
> if
> > we were to implement our own session Subscriber, but I don't see it
> > happening that often:
> >  - Direct ADBA use might be limited to driver implementors which will
> > either understand and test for this small requirement or just use an
> > existing reactive lib
> >  - a Subscriber that only receives zero or one value is pretty trivial to
> > implement
> >  - ADBA should aim to make it easy for implementors to expose their db
> > behaviors in an isolated way instead of eagerly forcing coordination with
> > CompletionStage based API. A low level contract like RS or ADBA should
> > encourage behavior first because this is a behavior contract above all.
> >  - nothing prevents the contract to introduce default CompletionStage API
> > relying on abstract/non-default Publisher based API, but I would rather
> see
> > such conversion util on Flow.Publisher directly.
> >
> > I wasn't present at this meetup but I'm pretty happy the community here
> was
> > able to discuss with Douglas. I should come to those events more often :D
> >
> > Cheers !
> >
> >
> > On Sat, Jul 28, 2018 at 2:29 AM, Lukas Eder <lukas.eder at gmail.com>
> wrote:
> >
> > > As this topic has been discussed many times on this list before with no
> > > success, I'm very curious to learn what kinds of arguments at the SFJUG
> > > finally made you change your mind about the topic. I'm sure I can
> learn a
> > > trick or two in persuasive techniques :-)
> > >
> > > Am Do., 26. Juli 2018 um 17:54 Uhr schrieb Douglas Surber <
> > > douglas.surber at oracle.com>:
> > >
> > > > I presented ADBA at the San Francisco Java Users Group last night. It
> > was
> > > > great. There were a number of folks who were strong advocates of
> > reactive
> > > > streams and we talked for well over an hour after the presentation
> > ended.
> > > > The kind of feedback we got last night is critical to the future
> > success
> > > of
> > > > this project.
> > > >
> > > > This discussion resulted in a concrete proposal to make ADBA better
> > > > integrate with reactive streams. I’m working on the API updates in a
> > > branch
> > > > and will push that branch ASAP. At present this is strictly a idea
> > under
> > > > discussion as it is a substantial change and we won’t go down this
> path
> > > > without more discussion from the wider community.
> > > >
> > > > The proposal is easy to describe though there are definitely some
> > tricky
> > > > bits in the actual API design.
> > > >
> > > >  - Replace Submission everywhere with java.util.concurrent.Flow.
> > > Publisher
> > > >  - Replace ParameterizedOperation.set(String, CompletionStage,
> SqlType)
> > > > with set(String, Publisher, SqlType)
> > > >  - Make DataSource a Publisher<Session>
> > > >
> > > > That’s the core idea but there will be other changes. Effectively
> this
> > > > replaces all uses of CompletionStage with Publisher. Not exactly
> > because
> > > it
> > > > also removes Submission as it is not needed.
> > > >
> > > > I have one small question. CompletionStage<Void> is ok. It is used to
> > > > signal that an Operation completed with no result. Is Publisher<Void>
> > > ok? I
> > > > assume that such a Publisher could only call onComplete or onError
> > which
> > > is
> > > > just what is needed for these use cases.
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Stéphane*
> > --
> >
>