[
https://issues.apache.org/jira/browse/DERBY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478665
]
Mike Matrigali commented on DERBY-2336:
---------------------------------------
Currently both heap and btree has the 1st row on page 0 as a free format
"metadata" row. There will need to be upgrade support but it can be handled
"on-the-fly" depending on what new info you want to add (ie. basically it is
easy if there is a workable default the missing data for old tables - so for
instance in this discussion existing tables would somehow be set with the
UCS_BASIC collation).
By on the fly I mean automatically when the table is accessed rather than as
part of the boot upgrade process.
There is actually some dead code in
java/engine/org/apache/derby/impl/store/access/btree/index/B2I.java :
(writeExternal_v36 and readExternal_v36) showing how we handled a pre-derby
upgrade to this metadata when we added
the storing of ascending/descending information.
I'll look at getting rid of the dead code.
The cost is disk space in page 0 which is the root page and thus a level is
added to the btree sooner
The limitation is that all the info in the metadata has to fit on the page.
So for instance I would not like to add a possibly long
string for every column.
Since the info we are setting is really one piece of info per db, setting it
once per table or worse once per column seems overkill. We
may want to do that in the future, and we have the infrastructure to do it when
we need to - but should we do it now?
So we could do this but I still wonder about getting this info and packaging
it up for every template call to the datatype. Note that these
template creations don't just happen for recovery. They happen during other
normal forward processing operations. Some examples
are that we need a scratch template to do a search on a btree, we need some
scratch templates to do btree splits, we create some
templates for bulk operations from heap and btree (like hash scan result sets).
> Enable collation based ordering for CHAR data type.
> ---------------------------------------------------
>
> Key: DERBY-2336
> URL: https://issues.apache.org/jira/browse/DERBY-2336
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mamta A. Satoor
> Attachments: DERBY_LocalFinder_CodeCleanup_diff_V01.txt,
> DERBY_LocalFinder_CodeCleanup_stat_V01.txt
>
>
> I am breaking down the Parent task DERBY-1478 (Add built in language based
> ordering and like processing to Derby) into multiple sub tasks. One of them
> is to concentrate on enabling the collation based ordering on (hopefully the
> simplest of all the character data types) CHAR data type. This task in itself
> might need subtasks if it is later found that it can be subdivided into
> multiple smaller steps.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
