db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 21:20:44 GMT


Rick Hillegas wrote:

>>
>> Thanks, Mike. This overhead seems pretty small to me. It's hard for me 
>> to predict whether this is useful generality or over-design.
>>
>> In the SQL standard, collations can be declared per column. That 
>> affects index descriptors. In addition, via CASTs, collations can be 
>> declared per sortable expression in an ORDER BY clause. That affects 
>> the sorter. I'm not the person scratching this initial itch. I just 
>> want to register my instinct to design-in the generality up front. I 
>> think this has two advantages:
>>
>> 1) It will remove an upgrade issue later on when someone wants to 
>> implement more of the SQL collation support.
>>
>> 2) It generally lowers the barrier to implementing more of the standard.
>>
>> Regards,
>> -Rick
> 
I am just not sure how comfortable I feel forcing an upgrade issue on a
developer for a particular feature that is not their itch.   Mamta is 
trying to solve single collation database problem, not full SQL 
collation support.

Your suggestion may get us more there, not arguing that.  But a solution
shorter along an agreed upon direction seems fine to me, and I would not
hold up a developer contribution that did that.  If the community feels 
that
4 new classes is ok, but 4 new types is not the right direction then
it is reasonable to work with the community to get the direction right.

I am waiting on Dan's reply as I think there are SYSTABLES and/or 
SYSCOLUMNS metadata changes necessary that haven't been discussed.  If 
so I think these are actually more upgrade work than the store ones
(I am not sure, I know exactly how to do the store upgrade ones - no 
idea what is involved in SYSCOLUMNS/SYSTABLES upgrades).  A real 
advantage of original proposal to have new format ids was I think there 
was no upgrade necessary.  I still don't really understand the upgrade
ramifications as the current proposal only affects newly created 
databases, so in theory there is no upgrade per se.  But it may mean
that runtime code needs to handle multiple versions of metadata.
> 
> 
> 


Mime
View raw message