Bernt M. Johnsen wrote:
"aa" as one letter was removed from the Norwegian language in 1938 ("å"
had been optional since 1917). It is only used in names today and it is
true what Anders says about the phonebook (also about the foreign names
where "aa" is treated like two letters). I don't think it would be wise
to not let "a.*" match "Aasen" (wich in modern writing would be Åsen).
Thank you so much Knut Anders and Bernt for the clarification on "aa".
I guess now I need a new example and need to understand how Locale
specific LIKE processing is functionally different than regular like
behavior and when it is required.
The user I have been working with is actually migrating from Cloudscape
5.1.60 National Character types and the goal was to get a workaround to
achieve the same behavior in Derby. The example came from the doc:
http://publibfi.boulder.ibm.com/epubs/html/cloud51/doc/html/coredocs/sqlj105.htm#1178996
Clearly the Derby code still has the code path for the National Type
special processing.
In org.apache.derby.iapi.types.SQLChar We have a separate code path for
National Character types that passes the Collator.
How is this functionally different than LIKE processing for regular
character types? Can anyone think of another example where this special
processing might be needed?
Thanks
Kathey
Below is a SQLChar code snippet for reference.
public BooleanDataValue like(DataValueDescriptor pattern)
throws StandardException
{
Boolean likeResult;
if (! isNationalString())
{
// note that we call getLength() because the length
// of the char array may be different than the
// length we should be using (i.e. getLength()).
// see getCharArray() for more info
char[] evalCharArray = getCharArray();
char[] patternCharArray = ((SQLChar)pattern).getCharArray();
likeResult = Like.like(evalCharArray,
getLength(),
patternCharArray,
pattern.getLength());
}
else
{
SQLChar patternSQLChar = (SQLChar) pattern;
likeResult = Like.like(getIntArray(),
getIntLength(),
patternSQLChar.getIntArray(),
patternSQLChar.getIntLength(),
getLocaleFinder().getCollator());
}
