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] Commented: (DERBY-2336) Enable collation based ordering for CHAR data type.
Date Tue, 06 Mar 2007 23:43:24 GMT

    [ 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:

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

View raw message