Hello.
I have surveyed code where length information is/may be written to disk.
Reading code around StoredPage and tracing execution with jdb,
I could not find code to write whole length information of long column
as value in field header in disk page format.
// I read that length of information divided in pages seems to be recorded.
// But not sure why this divided length was not be seen in jdb execution
of test programs...
I read length information of long column value is skipped to be recorded
and
think this is why testLob4.java was resulted as in
http://issues.apache.org/jira/browse/DERBY-782#action_12361194.
I have next questions.
Q1 :
In the view of architecture of disk page format, is it impossible to
record length information of long column?
I know very little about disk page format,
however, there seems to be no explicit description in the document
(http://db.apache.org/derby/papers/pageformats.html)
to conclude that it is impossible.
Q2 :
I read that length information of long column value is skipped to be
recorded.
However, does any other one have other information ?
I'm not so confident ...
Best regards.
Tomohito Nakayama (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-782?page=comments#action_12361194 ]
Tomohito Nakayama commented on DERBY-782:
-----------------------------------------
I have tried and found length information, which is ignored now, does not have
correct value.
[EMAIL PROTECTED]:~/derby/test/20051223$ runProgram.sh testLob4
Initializing jdb ...
stop at org.apache.derby.impl.jdbc.BinaryToRawStream:94
Deferring breakpoint org.apache.derby.impl.jdbc.BinaryToRawStream:94.
It will be set after the class is loaded.
run
run testLob4
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
VM Started: Set deferred breakpoint
org.apache.derby.impl.jdbc.BinaryToRawStream:94
Breakpoint hit: "thread=main",
org.apache.derby.impl.jdbc.BinaryToRawStream.<init>(), line=94 bci=252
94 int lenInBits = (((bl & 0xff) << 24) | ((v2 & 0xff) << 16) | ((v3
& 0xff) << 8) | (v4 & 0xff));
main[1] eval b1
com.sun.tools.example.debug.expr.ParseException: Name unknown: b1
b1 = null
main[1] eval bl
bl = 0
main[1] eval v2
v2 = 0
main[1] eval v3
v3 = 0
main[1] eval v4
v4 = 0
main[1] cont
Here goes 1st stream
0
1
2
length:0
Here continue 1st stream
3
4
5
The application exited
Improvement on org.apache.derby.impl.jdbc.EmbedBlob#length()
------------------------------------------------------------
Key: DERBY-782
URL: http://issues.apache.org/jira/browse/DERBY-782
Project: Derby
Type: Bug
Components: JDBC
Reporter: Tomohito Nakayama
Attachments: testLob4.java
Now, org.apache.derby.impl.jdbc.EmbedBlob#length() method read out whole
BinaryToRawStream to know exact length.
On the other hand, BinaryToRawStream have some commented-out inplementation of
having information for length.
I think the information of lengh in BinaryToRawStream should be restored to be
used in .org.apache.derby.impl.jdbc.EmbedBlob#length(), because read out whole
stream can be expensive processing when streamed information was large.
There exists a subject that reliability of lengh information in
BinaryToRawStream is unknown.
--
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
