Mamta Satoor wrote:
Dan, why would we need to override the StringDataValue
getValue(RuleBasedCollator collation) method in CollatorSQLChar? I think
it will be sufficient to implement this method in SQLChar with following
pseudocode
StringDataValue getValue(RuleBasedCollator collation)
{
if (collation == null)
{
// Just need UCS_BASIC collation, so just return myself.
return this;
}
CollatorSQLChar s = new CollatorSQLChar();
s.setValue(this);
s.setCollator(collation);
return s;
}
I see this method being called when store is trying to construct a
template row of DVDs based on the format ids and collation type that
store is aware of. Since the formatid for character types will always
correspond to SQLChar (the base class)(for simplicity, I am only talking
in terms of SQL type CHAR. Same logic applies for other SQL
character types) , the only thing that store might want is to use the
super class CollatorSQLChar as DVD if the collation type is
1(TERRITORY_BASED). When do you see the need for Derby code wanting to
go from CollatorSQLChar to SQLChar?
1) When needing to collate using USC_BASIC.
2) If CollatorSQLChar does not override that getValue(RuleBasedCollator
collation) then the class would not be honoring the api contract, which
will eventually lead to bugs as other new code assumes the class is
honoring the contract of the api.
Dan.
