<div dir="ltr"><div dir="ltr">On Wed, Jul 10, 2024 at 12:05 PM Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <div>Le 2024-07-10 à 18 h 00, Archie Cobbs a
      écrit :<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>
          <p>So would you accept a solution to this problem in the
            java.sql package instead? For example by adding two new
            methods:</p>
          <div class="gmail_quote">
            <div style="margin-left:40px"><span style="font-family:monospace">java.sql.Blob.asByteBuffer()</span></div>
            <div style="margin-left:40px"><span style="font-family:monospace">java.sql.Clob.asCharBuffer()</span></div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Yes, it would work for me if JDBC drivers provide their own
      implementation. But it would not be exactly equivalent. A <font face="monospace">Blob.asByteBuffer()</font> 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 <font face="monospace">Optional</font>.<br></p></div></blockquote><div>But the API already has that problem - see <span style="font-family:monospace">Blob.getBytes()</span>.</div><div><br></div><div>So we wouldn't be adding any new constraints on how it must behave.</div><div><br></div><div>In any case, the API seems designed to let you choose how you want to access the data - <span style="font-family:monospace">Blob.getBytes()</span> for random access, <span style="font-family:monospace">Blob.getBinaryStream()</span> for stream access.</div><div><br></div><div>The bug here is that <span style="font-family:monospace">Blob.getBytes()</span> 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.<br></div><div><br></div><div>The nice thing about a <span style="font-family:monospace">Blob.asByteBuffer()</span> 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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <p>By contrast, the <font face="monospace">ByteArrayInputStream.asByteBuffer()</font>
      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.</p></div></blockquote></div><div>I'm not opposed to this either, but it's a separate (nice) idea.</div><div><br></div><div>I'm curious to hear what other people think about both ideas... <br></div><div><br></div><div>-Archie<br></div><div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div></div>