openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fay Wang (JIRA)" <>
Subject [jira] Commented: (OPENJPA-130) Streaming LOB support
Date Sat, 12 Jun 2010 01:24:14 GMT


Fay Wang commented on OPENJPA-130:

The OPENJPA-130-DB2.patch provides streaming lob support for DB2. DB2 supports direct setBinary/CharacterStream
call. This is unlike Oracle/Mysql, where an insert of empty stream is inserted first followed
by an update of actual stream. The catch with DB2 is that for setIBinary/CharacterStream,
the length is required for JDBC 3. When setBinaryStream is called, the length can be obtained
by InputStream.available(). However, there is no API to get the length for Reader when setCharacterStream
is called. In JDBC 4, this problem is resolved as setBinary/CharacterStream can be called
without the length input parameter.  The patch attached works properly in the following conditions:
  (1) JDBC 3: setBinaryStream works fine, but setCharacterStream will not work as the length
of available char in the reader can not be obtained. 

  (2) JDBC 4: setBinary/CharacterStream work fine.

The test case org.apache.openjpa.jdbc.meta.strats.TestInputStreamLob and org.apache.openjpa.jdbc.meta.strats.TestReaderLob
works fine when the above patch applies to the openjpa-trunk with JDBC 4.

> Streaming LOB support
> ---------------------
>                 Key: OPENJPA-130
>                 URL:
>             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.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 (for BLOBs) and (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.

View raw message