[
https://issues.apache.org/jira/browse/DERBY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478638
]
Mike Matrigali commented on DERBY-2336:
---------------------------------------
The reality is that there isn't really "recovery" code involved. It is just
store code that happens to be running at recovery time (one of the
good things about derby is that redo recovery path is really the same path
through the code as forward running recovery). The problem
comes in that with the old system of pulling the collation info off the context
stack is that the setup of the info onto the context stack can't
be from some code "above" store as at recovery time there is no code "above"
store.
To answer dan's question about the meta data:
Store currently maintains an array of format id's per table, one for each
table/index. Many of the store interfaces the store never needs to
create an object to read or write data to/from disk. Most of the interfaces
include an empty or a full object passed in from the caller. But
in some cases store goes ahead and creates empty objects using format id's.
The Monitor currently provides some interfaces to
generate empty datatype objects based on format id's.
For example the code in
java/engine/org/apache/derby/impl/store/access/conglomerate/TemplateRow.java
uses the following to generate an object of the correct
type given a format id:
Monitor.newInstanceFromIdentifier(format_ids[i])
So if we want to "pass" in the info into the datatype, rather than have the
datatype pull it from a context then one option would be to
create something like Monitor.newInstanceFromIdentifier(format_id,
collation_info); And similar changes to any other Monitor supported
interface to create a datatype. Then the problem just turns into getting the
correct info into the various monitor calls. Above the store
maybe the compiler could generate 1 arg calls when it knew there was no
collation info. In the store I think it would be least ugly to
always generate 2 arg calls, but it is extra overhead for the non-collation
path.
> 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.
