Flow.Processor for Operation submission

[Dávid Karnok]

> Calling Subscription.onNext with any
>   * Operation that is not a member of this OperationGroup, that is
>   * was not created by calling one of the Operation factory methods on
this
>   * OperationGroup, will throw IllegalArgumentException.

Processor.onNext must not throw, therefore an invalid onNext item should
cancel the Subscription and signal onError to the Publisher side of the
Processor.

> Still thinking about how to publish rows.

In rxjava-jdbc, ResultSet is used as a lambda parameter and the instance
shown to the lambda should not escape it, i.e.,

<T> Flow.Publisher<T> convert(Function<Row, T> mapper);

2017-10-11 22:05 GMT+02:00 Douglas Surber <douglas.surber at oracle.com>:

> I have found what at first glance appears to be a non-hacky way to use
> Flow to channel Operations to an OperationGroup. It’s not perfect. The
> limitation that published Operations must be member Operations of the
> Operation group is unfortunate but absolutely necessary. Otherwise I think
> it is ok.
>
> Delete Connection.onSubscribe.
>
> Add the following to OperationGroup:
>
>   /**
>    * Returns a Flow.Processor that subscribes to a sequence of Operations
> and
>    * publishes a sequence of corresponding Submissions. The Operations must
>    * be members of this OperationGroup. Calling Subscription.onNext with
> any
>    * Operation that is not a member of this OperationGroup, that is
>    * was not created by calling one of the Operation factory methods on
> this
>    * OperationGroup, will throw IllegalArgumentException. The method
>    * Subscription.onNext will call submit on each Operation it is passed
>    * and publish the resulting Submission. Since an Operation can only be
>    * submitted once, submitting an Operation and calling onNext with that
>    * submitted Operation will throw IllegalStateException.
>    *
>    * Each call to this method returns a new Flow.processor. The Submissions
>    * published to each Processor are exactly those generated by calling
>    * submit on the Operations passed as arguments to onNext on the same
> Processor.
>    *
>    * Note: If any Operation is submitted directly, that is by calling
> submit
>    * rather than passing it to onNext, the Submission returned by the
> submit
>    * call will not be published.
>    *
>    * @return a Flow.Processor that accepts Operations and generates
> Submissions
>    */
>   public Flow.Processor<Operation<T>, Submission<T>> operationProcessor();
>
> Comments?
>
> Still thinking about how to publish rows.
>
>
> Douglas




-- 
Best regards,
David Karnok