db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject some comments on collation wiki page
Date Tue, 03 Apr 2007 06:22:56 GMT
I have included some comments based on th following wiki page:

 > 6)Store needs a way to determine the collation type for a given DVD. 
This collation type will then be saved in the column metadata. Provide 
the api on DVD to return the correct collation type.
     Just an addition here.  The way I expect this info to get down to store
     is that the template passed in when creating a conglomerate will have
     DVD's that have the correct collation id associated with them.
     This should be true for both btree and heap conglomerate creates, you
     should update iapi interface doc, but I don't think the actual args
     to the interface change.

     I assume the api is something like int getCollateId() on a DVD.

 >
 > 7)BasicDatabase needs to set the Locale value in the DVF after DVF 
has booted. Probably with an api like DVF.setLocale(Locale). DVF will 
use this Locale object to construct the correct Collator in case user 
has requested territory based collation through jdbc url at database 
create time.
 >
Need to somehow test a store btree recovery to make sure this works in the
redo recovery case.

 > Store changes
 >
 > 1)Store column level metadata for collate in Store. Store keeps a 
version number that describes the structure of column level metadata. 
For existing pre-10.3 databases which get upgraded to 10.3 and for new 
10.3 databases with default collatoin(UCS_BASIC), the structure of 
column level metadata will remain same as 10.2 structure of column level 
metadata, ie they will not include collate information in their store 
metadata. A new version would be used in Store for structure of column 
level metadata if the newly created 10.3 database has asked for 
territory based collation. In other words, information about collate 
will be kept in Store column level metadata only if we are working with 
a 10.3 newly created database with territory based collation. This 
approach will make sure that we do not have to do an on-disk store 
metadata upgrade when upgrading a pre-10.3 database to 10.3 version.
 >
This is not exactly what I expected.  I think there should be a single 
10.3 metadata format that includes collation information (whether it is 
default or not).  The actual format of the data can optmize as 
appropriate for non-default values if we think that is worth it.  I 
think the right thing to do is do
only manage either 10.3 version store metadata or pre-10.3 - and not base it
on whether there is a non-default collate or not.  The actual written format
of the 10.3 metadata may optimize the case where there is no non-default
collate - but it is still a 10.3 version.

So the world breaks down into:
pre-10.3 db's, which includes dbs that are running against 10.3 but only
     soft upgrade.
     o These db's never get the 10.3 metadata format

hard upgrade 10.3 db's
     o Code will read both pre and post 10.3 metadata.  All new 
conglomerates
       always write the 10.3 version metadata.  The code has to read both
       old and new formats.

new 10.3 db's
     o code will only write 10.3 metadata.

So what I was expecting was:

1)Store column level metadata for collate in Store. Store keeps a 
version number that describes the structure of column level metadata. 
For existing pre-10.3 databases which get soft upgraded to 10.3, the 
structure of column level metadata will remain same as 10.2 structure of 
column level metadata, ie they will not include collate information in 
their store metadata.
For any conglomerate created in a 10.3 new database or a 10.3 hard 
upgraded database a new version would be used in Store to include 
information about the collation for each column's metadata stored.



 > 2)Currently, store uses Monitor to create DVD template rows. The 
logic of creating DVDs using formatids should be factored out from 
Monitor into DataValueFactory. Talking in terms of code, 
RowUtil.newClassInfoTemplate should call DVF.classFromIdentifier rather 
than Monitor.classFromIdentifier.
     I believe there are more than one of these Monitor interfaces that will
     have to be moved in DVF.
 >
 > 3)This item is related to item 2. With Derby 10.3, collation type 
will be the additional metadata in store for each column. When store 
will call DVF to create DVD template row, it will pass the formatids and 
the collation types. DVF will need to be able to assoicate the correct 
Collator with the DVD for Char datatypes depending on the collation 
type. And in order to find the correct Collator, DVF needs to know the 
locale of the database. This locale information will be set on DVF using 
a new method on DVF called void setLocale(Locale). This call will be 
made by BasicDatabase after DVF has finished booting and before store 
starts booting.
 >

I think you should add an item to track the work in the sorter.  Maybe 
you are
tracking this as part of the aggregate items?  I know there are some 
template stuff specific to the sorter.  You should at least make sure to 
test both a sort that is in memory and a sort that is too big to fit 
into memory that includes special collation stuff.



Mime
View raw message