douglas.surber at oracle.com
Mon Jul 30 19:47:02 UTC 2018
I wouldn’t say I changed my mind. What did change is the RS supporters came up with a concrete suggestion. Given a specific concrete description it was worth the time to create a branch so people would have something to actually look at. I’ve said it many times before and I’ll repeat it one more time. If you don’t like something the best way to get it changed is to offer a concrete alternative.
I have serious reservations about the proposal. Which is not to say I’m against it. But it has disadvantages as well as allegedly advantages in certain use cases. I write “allegedly” because I don’t have the expertise to judge the claims. I expect the people who made this suggestion to make their case on this list. Unless this list reaches (more or less) consensus in support of something like this approach, its going to be hard to make the case to the JCP EC and the JDBC EG.
My goal is to standardize a non-blocking database access API in the near future. I don’t much care what it looks like so long as it meets the goals.
> On 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 <mailto: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.
More information about the jdbc-spec-discuss