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
DVD/SQLChar
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.
