[
https://issues.apache.org/jira/browse/DERBY-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3907:
-----------------------------------
Attachment: derby-3907-2c-header_write_preparation.stat
derby-3907-2c-header_write_preparation.diff
Patch 'derby-3907-2c-header_write_preparation.diff' is ready for review.
A description of the changes:
o EmbedResultSet and EmbedPreparedStatement
Started using the new ReaderToUTF8Stream constructor, where the stream
header is passed in. Also started to treat the DataValueDescriptor as a
StringDataValue, which should always be the case at this point in the code.
o ReaderToUTF8Stream
Added field 'header', which holds a StreamHeaderHolder coming from a
StringDataValue object. Updated the constructors with a new argument. The
first execution of fillBuffer now uses the header holder to obtain the header
length, and the header holder object is consulted when checking if the header
can be updated with the length after the application stream has been drained.
Note that updating the header with a character count is not yet supported. This
will be added in another patch together with the handling of the new header
format.
o StringDataValue
Added new method generateStreamHeader.
o SQLChar
Implemented generateStreamHeader, which always return a header for a stream
with unknown length (see the constant). In most cases, the header will be
updated after the stream has been drained. The exception is when the data
values for VARCHAR and LONG VARCHAR are too long to be held in the byte buffer
in ReaderToUTF8Reader, which can only happen when the string contains
characters that require a two or three byte representation.
o SQLClob
Added a constant for a 10.5 stream header holder representing a stream with
unknown character length. Also updated the use of the ReaderToUTF8Stream
constructor.
o StreamHeaderHolder
Holder object for a stream header, containing the header itself and the
following additional information; "instructions" on how to update the header
with a new length, if the length is expected to be in number of bytes or
characters, and if an EOF marker is expected to be appended to the stream. The
object is considered immutable, but it is not copying the byte arrays passed in
to the constructor. I found this unnecessary because this code is being called
by internal code only, but should it still do defensive copying?
o UTF8UTilTest
Updated usage of the ReaderToUTF8Stream constructor, and replaced the
hardcode byte count to skip with a call to the header holder object.
o ClobTest (jdbc4)
Added some simple tests inserting and fetching Clobs to test the basics of
stream header handling.
o StreamTruncationTest
New test testing truncation of string data values when they are inserted as
streams. Note the not-so-elegant error reporting (see catch clause in
insertSmall)...
> Save useful length information for Clobs in store
> -------------------------------------------------
>
> Key: DERBY-3907
> URL: https://issues.apache.org/jira/browse/DERBY-3907
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, Store
> Affects Versions: 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-3907-1a-alternative_approach.diff,
> derby-3907-2b-header_write_preparation.diff,
> derby-3907-2b-header_write_preparation.diff,
> derby-3907-2b-header_write_preparation.stat,
> derby-3907-2c-header_write_preparation-PREVIEW.diff,
> derby-3907-2c-header_write_preparation-PREVIEW.stat,
> derby-3907-2c-header_write_preparation.diff,
> derby-3907-2c-header_write_preparation.stat,
> derby-3907-3a-readertoutf8stream_cleanup.diff,
> derby-3907-3a-readertoutf8stream_cleanup.diff,
> derby-3907-3a-readertoutf8stream_cleanup.stat,
> derby-3907-3b-readertoutf8stream_cleanup.diff
>
>
> The store should save useful length information for Clobs. This allows the
> length to be found without decoding the whole data stream.
> The following thread raised the issue on what information to store, and also
> contains some background information:
> http://www.nabble.com/Storing-length-information-for-CLOB-on-disk-tp19197535p19197535.html
> The information to store, and the exact format of it, is still to be
> discussed/determined.
> Currently two bytes are set aside for length information, which is inadequate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
