From julien at julienviet.com  Sun Sep  2 20:34:22 2018
From: julien at julienviet.com (Julien Viet)
Date: Sun, 2 Sep 2018 22:34:22 +0200
Subject: Flow.Publisher<Void>
In-Reply-To: <CABY0rKP-Zm=_HOjnifPpO5WP0R76v0cHUMV16RxP6BDjWOcd6A@mail.gmail.com>
References: <44AD6DFF-A6C4-420F-B64A-267ED53F314B@oracle.com>
 <CABY0rKP-Zm=_HOjnifPpO5WP0R76v0cHUMV16RxP6BDjWOcd6A@mail.gmail.com>
Message-ID: <10D8B596-01E2-4F3C-8F80-B22073DFD351@julienviet.com>

Hi,

my personal opinion is that CompletionStage / Publisher based API are easier to read and understand without ambiguity as I can map CompletionStage to a single value and Publisher to a stream.

my 2c.

Julien

> On 27 Jul 2018, at 03:13, James Roper <james at lightbend.com> wrote:
> 
> Hi Douglas,
> 
> I'm not for this change.
> 
> One problem with it is that there are quite a number of other standard
> APIs, both in the JDK (eg the new HTTP client) as well as in Java EE (eg
> JAX-RS, CDI, and a number of the new MicroProfile APIs) plus a myriad of
> open source libraries that have already embraced CompletionStage as the
> abstraction to use to asynchronously provide exactly one value, or to
> signal completion (a la CompletionStage<Void>). Some of these APIs are
> looking to or have adopted Reactive Streams/juc.Flow, but only for
> streaming, not for asynchronous single values. When all libraries use the
> same abstraction for the same use case, then they become easy to use and
> integrate with each other. When they use different abstractions, then you
> need bridges to integrate them with each other, which has the effect of
> making it harder for end users to use them, the code they write becomes
> harder to read due to all the bridging wrappers, etc.
> 
> So, if let's say I need to load something from the database, then make an
> HTTP call, if both the database adapter and that HTTP client use
> CompletionStage, this is easy as:
> 
> CompletionStage<Response> response = database.executeQuery()
>  .thenCompose(result ->
> httpClient.makeRequest(convertResultToRequest(result)));
> 
> I can add other asynchronous operations from other libraries to my hearts
> content and the code still stays easy to read because everything is using
> the same abstraction. However, if ADBA used reactive streams for this, then
> you would need to convert the publisher to a CompletionStage. It would be
> the only API in the Java standards ecosystem that uses streams in this way,
> which would make it stand out like a sore thumb, every other Java standard
> that supported asynchronous IO would integrate nicely together using
> CompletionStage, but when it came to using ADBA, everyone would have to use
> a bridging wrapper.
> 
> Reactive streams is great for streams - I am a massive proponent of it
> being used for the right use case. But it includes a lot of mechanics (and
> performance overhead) to meet the needs that streams have, including
> handshaking to establish a subscription, and then tokens for backpressure.
> A single value made asynchronously available in the future is not a stream,
> it doesn't require back pressure because there's only one value, not
> potentially infinite, it doesn't require the overhead of a subscription
> because the semantics are much simpler. These things get in the way both
> performance wise and they also make it more complex to use and implement.
> Of course, you *can* use a stream to provide a single value, I'm not
> disputing that. You can also use a Collection to represent a single value
> that may or may not be present - but that's not what it's designed for,
> java.util.Optional is designed and optimised for that, and makes it much
> clearer to uses when they see it what is actually being provided. The same
> goes with CompletionStage vs Publisher.
> 
> Regards,
> 
> James
> 
> On Fri, 27 Jul 2018 at 02:04, Douglas Surber <douglas.surber at oracle.com>
> wrote:
> 
>> 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.
>> 
>> 
>> 
>> 
> 
> -- 
> *James Roper*
> *Senior Developer, Office of the CTO*
> 
> Lightbend <https://www.lightbend.com/> ? Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>


From alexander.kjall at gmail.com  Mon Sep 17 19:08:11 2018
From: alexander.kjall at gmail.com (=?UTF-8?Q?Alexander_Kj=C3=A4ll?=)
Date: Mon, 17 Sep 2018 21:08:11 +0200
Subject: Regarding AdbaType.JAVA_OBJECT
Message-ID: <CAOuTi9WA6x80ra9rLmqShuJTs_bk1R9pdGGE6DbAhw+3u=O_XA@mail.gmail.com>

Hi

I would like to ask about how the JAVA_OBJECT type is supposed to be
implemented.

One way to do it would be to use java's built in serialization, but
that's impossible without creating a serialization security hole in
the driver, same if I serialize it to xml/json and let arbitrary types
be deserialized.

One way to maybe implement it without security holes is to let the end
user register classes that are allowed, but that feels very clunky.

I'm also questioning the usefulness of this feature in regard to all
the serialization security holes java are suffering from, is it really
needed or can it be dropped?

best regards
Alexander Kj?ll

From douglas.surber at oracle.com  Mon Sep 17 19:36:49 2018
From: douglas.surber at oracle.com (Douglas Surber)
Date: Mon, 17 Sep 2018 12:36:49 -0700
Subject: Regarding AdbaType.JAVA_OBJECT
In-Reply-To: <CAOuTi9WA6x80ra9rLmqShuJTs_bk1R9pdGGE6DbAhw+3u=O_XA@mail.gmail.com>
References: <CAOuTi9WA6x80ra9rLmqShuJTs_bk1R9pdGGE6DbAhw+3u=O_XA@mail.gmail.com>
Message-ID: <53F91F01-2BA4-4DB2-A3B4-AC20A94D9410@oracle.com>

JAVA_OBJECT is included in AdbaType solely because it is in JDBCTypes and JDBCType. How and if it is implemented is entirely up to the database vendor and/or driver implementer. Or we can remove it.

Douglas

> On Sep 17, 2018, at 12:08 PM, Alexander Kj?ll <alexander.kjall at gmail.com> wrote:
> 
> Hi
> 
> I would like to ask about how the JAVA_OBJECT type is supposed to be
> implemented.
> 
> One way to do it would be to use java's built in serialization, but
> that's impossible without creating a serialization security hole in
> the driver, same if I serialize it to xml/json and let arbitrary types
> be deserialized.
> 
> One way to maybe implement it without security holes is to let the end
> user register classes that are allowed, but that feels very clunky.
> 
> I'm also questioning the usefulness of this feature in regard to all
> the serialization security holes java are suffering from, is it really
> needed or can it be dropped?
> 
> best regards
> Alexander Kj?ll


From alexander.kjall at gmail.com  Wed Sep 19 13:39:28 2018
From: alexander.kjall at gmail.com (=?UTF-8?Q?Alexander_Kj=c3=a4ll?=)
Date: Wed, 19 Sep 2018 15:39:28 +0200
Subject: Regarding AdbaType.JAVA_OBJECT
In-Reply-To: <53F91F01-2BA4-4DB2-A3B4-AC20A94D9410@oracle.com>
References: <CAOuTi9WA6x80ra9rLmqShuJTs_bk1R9pdGGE6DbAhw+3u=O_XA@mail.gmail.com>
 <53F91F01-2BA4-4DB2-A3B4-AC20A94D9410@oracle.com>
Message-ID: <35020145-fbc2-1931-49ad-c9613ed10e8d@gmail.com>

My personal opinion is that this feature isn't widely in use and is very 
hard or maybe impossible to implement without deserialization security 
holes, so the gains from dropping it outweights the loss of functionality.

Just my 0.02?

//Alex

On 17. sep. 2018 21:36, Douglas Surber wrote:
> JAVA_OBJECT is included in AdbaType solely because it is in JDBCTypes and JDBCType. How and if it is implemented is entirely up to the database vendor and/or driver implementer. Or we can remove it.
>
> Douglas
>
>> On Sep 17, 2018, at 12:08 PM, Alexander Kj?ll <alexander.kjall at gmail.com> wrote:
>>
>> Hi
>>
>> I would like to ask about how the JAVA_OBJECT type is supposed to be
>> implemented.
>>
>> One way to do it would be to use java's built in serialization, but
>> that's impossible without creating a serialization security hole in
>> the driver, same if I serialize it to xml/json and let arbitrary types
>> be deserialized.
>>
>> One way to maybe implement it without security holes is to let the end
>> user register classes that are allowed, but that feels very clunky.
>>
>> I'm also questioning the usefulness of this feature in regard to all
>> the serialization security holes java are suffering from, is it really
>> needed or can it be dropped?
>>
>> best regards
>> Alexander Kj?ll


From davecramer at gmail.com  Wed Sep 19 13:47:38 2018
From: davecramer at gmail.com (Dave Cramer)
Date: Wed, 19 Sep 2018 09:47:38 -0400
Subject: Regarding AdbaType.JAVA_OBJECT
In-Reply-To: <35020145-fbc2-1931-49ad-c9613ed10e8d@gmail.com>
References: <CAOuTi9WA6x80ra9rLmqShuJTs_bk1R9pdGGE6DbAhw+3u=O_XA@mail.gmail.com>
 <53F91F01-2BA4-4DB2-A3B4-AC20A94D9410@oracle.com>
 <35020145-fbc2-1931-49ad-c9613ed10e8d@gmail.com>
Message-ID: <CADK3HHKCfPfqp6D5UcaG5NGTwMs=u5XKiSOoWNwQx0bjLpEmyw@mail.gmail.com>

Alexander,

Actually given that PostgreSQL is an OO database, it is probably the only
db that would make use of it!

You might want to reconsider your position

Dave Cramer


On Wed, 19 Sep 2018 at 09:39, Alexander Kj?ll <alexander.kjall at gmail.com>
wrote:

> My personal opinion is that this feature isn't widely in use and is very
> hard or maybe impossible to implement without deserialization security
> holes, so the gains from dropping it outweights the loss of functionality.
>
> Just my 0.02?
>
> //Alex
>
> On 17. sep. 2018 21:36, Douglas Surber wrote:
> > JAVA_OBJECT is included in AdbaType solely because it is in JDBCTypes
> and JDBCType. How and if it is implemented is entirely up to the database
> vendor and/or driver implementer. Or we can remove it.
> >
> > Douglas
> >
> >> On Sep 17, 2018, at 12:08 PM, Alexander Kj?ll <
> alexander.kjall at gmail.com> wrote:
> >>
> >> Hi
> >>
> >> I would like to ask about how the JAVA_OBJECT type is supposed to be
> >> implemented.
> >>
> >> One way to do it would be to use java's built in serialization, but
> >> that's impossible without creating a serialization security hole in
> >> the driver, same if I serialize it to xml/json and let arbitrary types
> >> be deserialized.
> >>
> >> One way to maybe implement it without security holes is to let the end
> >> user register classes that are allowed, but that feels very clunky.
> >>
> >> I'm also questioning the usefulness of this feature in regard to all
> >> the serialization security holes java are suffering from, is it really
> >> needed or can it be dropped?
> >>
> >> best regards
> >> Alexander Kj?ll
>
>

From douglas.surber at oracle.com  Wed Sep 19 16:18:34 2018
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 19 Sep 2018 09:18:34 -0700
Subject: Regarding AdbaType.JAVA_OBJECT
In-Reply-To: <35020145-fbc2-1931-49ad-c9613ed10e8d@gmail.com>
References: <CAOuTi9WA6x80ra9rLmqShuJTs_bk1R9pdGGE6DbAhw+3u=O_XA@mail.gmail.com>
 <53F91F01-2BA4-4DB2-A3B4-AC20A94D9410@oracle.com>
 <35020145-fbc2-1931-49ad-c9613ed10e8d@gmail.com>
Message-ID: <740FA084-43BD-4DC9-A647-D970506F1073@oracle.com>

Nothing in ADBA between Session.Builder.build and Session.close is mandatory. Supporting the various SessionProperties and DataSourceProperties is all optional as well. If it makes sense for a particular implementation to support a feature, it should. Better to use the standard API than create a new one. But if some ADBA feature does not make sense for a particular implementation that implementation should not support that feature. It is better for a feature not to be supported at all rather than being a mis-feature or poorly supported. App developers should be able to rely on the implementation. If something in ADBA would not work well with a particular implementation it should fail immediately. Any feature that works at all should work well.

Douglas

> On Sep 19, 2018, at 6:39 AM, Alexander Kj?ll <alexander.kjall at gmail.com> wrote:
> 
> My personal opinion is that this feature isn't widely in use and is very hard or maybe impossible to implement without deserialization security holes, so the gains from dropping it outweights the loss of functionality.
> 
> Just my 0.02?
> 
> //Alex
> 
> On 17. sep. 2018 21:36, Douglas Surber wrote:
>> JAVA_OBJECT is included in AdbaType solely because it is in JDBCTypes and JDBCType. How and if it is implemented is entirely up to the database vendor and/or driver implementer. Or we can remove it.
>> 
>> Douglas
>> 
>>> On Sep 17, 2018, at 12:08 PM, Alexander Kj?ll <alexander.kjall at gmail.com> wrote:
>>> 
>>> Hi
>>> 
>>> I would like to ask about how the JAVA_OBJECT type is supposed to be
>>> implemented.
>>> 
>>> One way to do it would be to use java's built in serialization, but
>>> that's impossible without creating a serialization security hole in
>>> the driver, same if I serialize it to xml/json and let arbitrary types
>>> be deserialized.
>>> 
>>> One way to maybe implement it without security holes is to let the end
>>> user register classes that are allowed, but that feels very clunky.
>>> 
>>> I'm also questioning the usefulness of this feature in regard to all
>>> the serialization security holes java are suffering from, is it really
>>> needed or can it be dropped?
>>> 
>>> best regards
>>> Alexander Kj?ll
> 


From mark at lawinegevaar.nl  Sat Sep 29 09:34:14 2018
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Sat, 29 Sep 2018 11:34:14 +0200
Subject: DatabaseMetaData.getVersionColumns BUFFER_LENGTH column
Message-ID: <bcdc18ff-78f1-9328-0a85-af289ccba54e@lawinegevaar.nl>

I'm currently implementing DatabaseMetaData.getVersionColumns for 
Jaybird, and I noticed that this defines the BUFFER_LENGTH column as 
"length of column value in bytes", while all other metadata methods that 
include BUFFER_LENGTH specify "is not used".

Is BUFFER_LENGTH really intended to be implemented for 
getVersionColumns, or is just leaving it null good enough? And if so, 
should the API documentation be amended?

Mark
-- 
Mark Rotteveel