On Wed, Jul 10, 2024 at 12:05 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Le 2024-07-10 à 18 h 00, Archie Cobbs a écrit :
>
> So would you accept a solution to this problem in the java.sql package
> instead? For example by adding two new methods:
> java.sql.Blob.asByteBuffer()
> java.sql.Clob.asCharBuffer()
>
> Yes, it would work for me if JDBC drivers provide their own
> implementation. But it would not be exactly equivalent. A
> Blob.asByteBuffer() method would be efficient when the JDBC driver loads
> all bytes anyway, but may be expansive if the JDBC driver was really doing
> streaming. Maybe some JDBC drivers do streaming only when the Blob size is
> over some threshold (I didn't verified). Since a Blob can be very large,
> wouldn't it be safer to avoid adding API that performs an unconditional
> loading of all bytes? Unless the plan was to return an Optional.
>
But the API already has that problem - see Blob.getBytes().
So we wouldn't be adding any new constraints on how it must behave.
In any case, the API seems designed to let you choose how you want to
access the data - Blob.getBytes() for random access, Blob.getBinaryStream()
for stream access.
The bug here is that Blob.getBytes() seems to force the driver to make a
copy of the entire blob (or at least the portion you want to access) simply
by the way it's designed - because the "copyness" is unspecified, a
defensive copy of the array data is required.
The nice thing about a Blob.asByteBuffer() method is that it would fix that
problem. And a smart implementation could download and cache regions of the
blob on demand as they were accessed, providing a continuous middle ground
between the current "all or none" downloading choices.
> By contrast, the ByteArrayInputStream.asByteBuffer() proposal never loads
> bytes that were not already in memory. Therefore, it can be used in a more
> opportunistic way ("only if all bytes happen to be in memory anyway,
> opportunistically use them directly without copy"). Also, it does not
> require changes in JDBC drivers, and could be used in contexts other than
> JDBC as well.
>
I'm not opposed to this either, but it's a separate (nice) idea.
I'm curious to hear what other people think about both ideas...
-Archie
--
Archie L. Cobbs
