Daniel John Debrunner (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-463?page=comments#action_12356742 ]
Daniel John Debrunner commented on DERBY-463:
---------------------------------------------
Sunitha, I don't think that is a problem because the api for
OutputStream.write(int b) is that it is a write of a byte, the top 24 bits are
discarded.
Thanks Dan. Thats right, I see it now.
There is a different serious problem with the class, nothing to do with this
patch, it's an existing problem.
The code use String(byte[]) to create a string from a byte array. This uses the
default platform encoding, which is typically not required
behaviour. Since this class is used for Clob.setAsciiStream I assume the
encoding should be ascii based.
Yes. I think it should be ascii based. Per the jdbc api for
Clob.setAsciiStream -" Retrieves a stream to be used to write _Ascii
characters_ to the |CLOB| value that this |Clob| object represents,
starting at position |pos|."
Though the performance of this class looks terrible if write(int) is used, at
least five objects created for eveny byte written!
In fact this class and the client Clob have code like this everywhere, as the
Clob is updated:
clob_.string_ = clob_.string_.concat(new String(newByte));
clob_.asciiStream_ = new java.io.StringBufferInputStream(clob_.string_);
clob_.unicodeStream_ = new
java.io.StringBufferInputStream(clob_.string_);
clob_.characterStream_ = new java.io.StringReader(clob_.string_);
Would probably be better to create most of those objects on demand, rather than
on every modification. I mean if the CLOB is modified
but the application never retrieives the ascii or character streams, what was
the benefit of creating them?
Good point. I'll open a jira for cleanup of this.
Thanks,
Sunitha.
