openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milosz Tylenda (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-130) Streaming LOB support
Date Sat, 12 Jun 2010 17:43:12 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878291#action_12878291
] 

Milosz Tylenda commented on OPENJPA-130:
----------------------------------------

Hi Fay. This is an interesting addition. I have a few remarks.

1. Please consider creating a new issue for this work. Then, when we create release notes
for OpenJPA 2.1.0, it will be clear that the new feature is there.

2. Small oversight:
+                    if (log.isTraceEnabled())
+                        log.error(ioe.toString(), ioe);

Also, there are unwanted empty lines between comments and method bodies.

3. Why are you doing the checks "if (ob instanceof InputStream)" and "if (ob instanceof Reader)"?
If they are necessary, what other instances are possible to come as method parameters?

4. It is my understanding that using InputStream.available() to determine the length is to
make the best effort possible while with JDBC 3. However, because the method is used regardless
of the JDBC version, I am afraid that in practice it will break the feature even for those
using JDBC 4. The semantics of available() is that it will rather return the number of bytes
untill the stream gets blocked instead of actual length of the stream. TestInputStreamLob
works fine because it uses memory streams and available() returns the actual stream length
but in a real world, users will rather use file or network streams and in such cases available()
will not return the actual length but some smaller value.

I would think of getting rid of using available() and limit the DB2 support to JDBC 4.

Let me know if you need more clarification.



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