db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3907) Save useful length information for Clobs in store
Date Wed, 05 Nov 2008 17:51:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-3907:

> I'm a bit unsure how to handle the format id issue.
> It is not clear to me what the differences between the various clob fields in
StoredFormatIds are:
For the reading and writing of the data to disk the SQL_CLOB_ID is the one.
It is associated with the SQLClob class.

The SQL layer when it creates a table gives the format id of each of the
collumns.  This format id is used by store to tell what object it should
create to interpret the bytes on disk.  So say you create a SQL_CLOB_VER2_ID,
and associated it with SQLClob2, and work the code such that new db's and/or
hard upgraded db's always use the new class/id when creating new tables.
Then Store will use SQLClob2 to read data into, and count on

to read and write your new format.

Note that for current SQLClob these are all inherited from SQLChar currently.

In general what has been done in the pase is to switch the format ids in the
new code such that the "current" version has the existing name, and that
the old version has the new name.  So SQLClob would get the new version id,
and a new class would get the old version id, something like SQLClob_10_4.java.

For an example check out:

Again this is only talking about the issue of reading/writing disk at store
level.  There may be other code with stream dependencies that thinks it
"knows" the format of the stream.  The way this kind of thing has been handled
in the past is to make the runtime version of the object always look like the
"current" format.  For past upgrades this has been easy as it usually is just
another field in the object that one can pick a default for if it is an old
version.  In this way it isolates the upgrade code to just the to/from
disk part of the code.  With streams this may be more challenging.

> In the current implementation, I think I need to access this information up to
 the JDBC level, i.e. in classes like StoreStreamClob, SQLClob and possibly a Re
sultSet class.
> To me it seems I need two versions of the SQL_CLOB_ID, but I'm not sure.
> Can anyone with more knowledge about the type system guide me?
> I do think we need a new format id, because the current format (two bytes that
 can have any values) makes it hard to add another stream header format.

> 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:
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
> 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.

View raw message