[ 
https://issues.apache.org/jira/browse/OPENJPA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fay Wang updated OPENJPA-130:
-----------------------------

    Attachment: OPENJPA-130-DB2-2.patch

It's not necessarily the length of the underlaying data, it's the amount of 
data that can be read without causing a resource to be blocked.  When using 
fully materialized lobs, this number is the length, but when using locators or 
progressive references, this number is the amount of data in the buffer. 

If the length is not known, it can be set to -1 in JDBC3.  (It's a JCC specific 
API).  Calling setCharacterStream(int, Reader) in JDBC 4 is the same as calling 
setCharacterStream(int, Reader, -1) in the JDBC 3 API.

> Streaming LOB support
> ---------------------
>
>                 Key: OPENJPA-130
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-130
>             Project: OpenJPA
>          Issue Type: New Feature
>          Components: datacache, jdbc, jpa, kernel
>            Reporter: Patrick Linskey
>            Assignee: Ignacio Andreu
>             Fix For: 1.1.0
>
>         Attachments: OPENJPA-130-2.patch, OPENJPA-130-3.patch, 
> OPENJPA-130-DB2-2.patch, OPENJPA-130-DB2.patch, OPENJPA-130.patch, 
> OPENJPA-130.patch
>
>
> BLOB and CLOB fields can only be mapped in their entirety in OpenJPA. It 
> would be nice to support fields of type java.io.InputStream (for BLOBs) and 
> java.io.Reader (for CLOBs).
> The usage pattern could look like so:
> @Entity
> public class Employee {
>     ...
>     private InputStream photoStream;
>     public void setPhotoStream(InputStream in) {
>         photoStream = in;
>     }
>     public InputStream getPhotoStream() {
>         return photoStream;
>     }
> }
> So, when the user wants to provide a stream, she will set the InputStream 
> field, and when the user wants to obtain a stream, she will use the field.
> The behavior of such an implementation would be a bit different than how 
> other fields work, in that if the user set the stream and then consumed it 
> within a single transaction, presumably no data would be written out to the 
> database at commit time. But that is the nature of streams.
> (FTR, I think that I stole this idea from an email Craig Russell sent out 
> years ago.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to