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: how should store get an object based on format id and collation id?
Date Tue, 17 Apr 2007 01:32:02 GMT

Daniel John Debrunner wrote:
> Mike Matrigali wrote:
>> Daniel John Debrunner wrote:
>>> Mamta Satoor wrote:
>>>> I spent some time on points 1(using Monitor to get dvd directly) and 
>>>> 3(optimized allocation, caching some of the work.) which requires us 
>>>> to solve the problem of how to get the InstanceGetter to return the 
>>>> correct DVD for character types. Let me first briefly describe how 
>>>> the InstanceGetter works for DVDs currently.
>>> I'm a little unclear on exactly the problem this is trying to solve. 
>>> I got a little lost in the details, but does it take account of the 
>>> fact that the registered format ids are system wide and there can be 
>>> databases with different default collations in the same system?
>>> Also the use of InstanceGetters seem to complicate this issue, once 
>>> one knows one has a collation type and one is using the 
>>> DataValueFactory then one can have methods on DVF that return 
>>> DataValueDescriptors directly, no need to go through the indirection 
>>> of InstanceGetters. They are a mechanism used when the type of the 
>>> object is not known, here the type is known as a DVD.
>>> One of the points to note is that the correct DVD type for collation 
>>> is only needed when collation is actually occurring. If a collator 
>>> based column is read in using SQLChar then it's not a problem as long 
>>> as a switch to the collator version occurs during comparisons. 
>>> Earlier I has suggested methods to perform this switch on 
>>> StringDataType, something like getCollationValue(int collationType).
>> I am stuck on this.  Is your proposal to carry around a collation type
>> field in the SQLChar class and delay the underlying association with
>> a class that does collation until the first method called that requires
>> collation?  I thought you specifically did not want a collation type
>> to be available from a dvd.  I am sure I am missing something in your
>> proposal.
> I'd assumed that every time a collation was needed that enough meta data 
> was available to determine the collation. For example with language 
> based comparisons the collation will be known at compile time and thus 
> can be used. For index based collation the metadata must be available 
> already today because the collations must be using the asc/desc flag.
> Assuming that is true, then no need to store the collation in the 
Can you explain more about how this would happen.  Currently a path
through store goes:

1) empty dvd created
2) dvd initiated from disk
3) dvd is compared to other dvd's created by step 1 and 2.  Step 3
    can happen many times reusing one dvd and changing the other
    dvd multiple times (ie. a search of the tree in index).

I was assuming store would input correct collate at step 2 and then 
compare happens using collation alred set up to do compares in step 3.

I am guessing you want no input of collate info at step 2 but some 
change at step 3, but not sure what.  Do want step 3 to create yet
a different dvd?  Or do you want to change the compare routines to take 
collate id's?

I was hoping for collation to be hidden from store within the datatype
rather than exposed on every compare call.

> Dan.

View raw message