You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <ji...@apache.org> on 2008/10/10 19:03:44 UTC

[jira] Updated: (DERBY-3907) Save useful length information for Clobs in store

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

Mike Matrigali updated DERBY-3907:
----------------------------------


upgrade comments:
o In keeping with the current Derby goals I believe any change of format should continue to support
   the hard/soft upgrade paradigm.  Given that any change will need to have code that supports both
   the old and new format.

o So then the decision is when to use the new format.  At high level (though not sure all are feasible)
   are:
   1) every different clob in existing table
   2) only new tables support new format, in hard upgraded db's support new format
   3) only newly created DB's support new format.

1) Off hand I don't think we have enough per data value information to figure out an olf format clob
     vs. a new format clob - but maybe someone else can come up with a magic sequence of initial
     bytes.  It would be nice if the new format made it so in the future other possible optimizations 
     could be handled on a per row basis - with some sort of format byte.
2) This option seems the most flexible and readily implemented.  By creating a new format id for
     the new type of clob then the code can be made to easily know the difference between a table
     of old clobs and new clobs.  If someone really wants to data upgrade an old db then an offline
     compress in a hard upgraded db should automatically do it, with the added benefit of defraging
     and compressing the tables.
3) I think this is sort of like #2 and is not really any less code.  

o Also there is a decision on what to do at hard upgrade time.  Either the newly hard upgrade db supports both formats or one had to do a per row data upgrade.  No Derby release has done this
(and it was never done before the code was donated to apache either).  My opinion would be to 
continue to support both formats.

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