Flow.Publisher<Void>

[Frédéric Montariol]

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