openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fay Wang (JIRA)" <j...@apache.org>
Subject [jira] Updated: (OPENJPA-130) Streaming LOB support
Date Mon, 14 Jun 2010 20:19:13 GMT

     [ 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.


Mime
View raw message