Daniel John Debrunner wrote:
Mamta Satoor wrote:
...
- At recovery time the btree uses the collation type and the data value
factory to setup its template row array correctly. Something like
for each dvd in row array
if (dvd instanceof StringDataValue)
dvd = dvd.getValue(dvf.getCharacterCollator(type));
Note that the store issue is not just a recovery time issue, templates
are required during normal runtime. Creation of these templates used
to show up (a long time ago) in performance analysis and work was done
to optimize the performance. So I am interested in making these
template creations as efficient as possible.
Your proposal above does not look right to me - it could just be I don't
understand where the psuedo code is. The code I expect in store would
be something like below - letting the datafactory do whatever is right
based on the format id and the collation, if store is going to "own" knowing
the collation of a given column then I would expect something like:
for each format id in row array
dvd = datavaluefactory.getObject(format id, character_collator_type)
note this means extra overhead for every object creation in the template.
To me it seems unfortunate to pass in this info per column, when at
least in 10.3 the current code it is one per database. I saw the
direction as:
o 10.3 only needs one collation per database so hide the info in the
datafactory, basically there is one DEFAULT collation per database.
Thus no need for second argument to datavaluefactory.getObject()
o future release needs to have different collations per conglomerate,
then at that time we can store a collator type per conglomerate - we
have mechanism today to upgrade on the fly. If we want to support
adding a collation to an existing database I would suggest continueing
the DEFAULT collation concept with some magic number representing
DEFAULT db collation in the datavaluefactory.getObject() call - which
would mean use db wide default rather than specify specific one. For
new databases we would not need default, we could at that time specify
one per conglomerate.
At this point we either change all the datavaluefactory.getObject()
calls to have 2 args and support DEFAULT_VALUE as second argument, or
maybe support both 1 and 2 arg calls - not sure.
0 future future release needs to have different collations per column,
then at that time we can store a collator type per column - we
continue to have mechanism to upgrade on fly as long as we can come up
with a default value for old tables. Same issues as above.
- setting the collation property remains in the data dictionary
- basic database sets the locale for the DataValueFactory after it boots
it, using a new method on DVF
void setLocale(Locale locale);
I think approaching the problem this way will lead to a cleaner solution
in the long term and be somewhat easier to implement.
Thanks,
Dan.
