db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3136) Cut down on object creations in LIKE clause implementation of territory based characters.
Date Thu, 25 Oct 2007 05:36:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537498

Mamta A. Satoor commented on DERBY-3136:

I incorporated the changes suggested by Knut into trunk using revision 588147. The commit
comments were as follows


Cut down on unnecessary String and CollationElementIterator objects creation in Like.java
class by changing the way we compare the character in value string vs character in the pattern

When working with database with UCS_BASIC collation, the 2 characters should be the same otherwise
we will return FALSE.

When working with territory based collation, if the 2 characters are the same, then we can
simply return TRUE because their collation elements will have to be same. But if the 2 characters
are not same, then use the RuleBasedCollator for the territory to see if those 2 different
characters match (ie they have same collation element(s) corresponding to them).

> Cut down on object creations in LIKE clause implementation of territory based characters.
> -----------------------------------------------------------------------------------------
>                 Key: DERBY-3136
>                 URL: https://issues.apache.org/jira/browse/DERBY-3136
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:,
>            Reporter: Mamta A. Satoor
>            Assignee: Mamta A. Satoor
> The LIKE clause for territory based characters was implemented correctly based on SQL
standards in DERBY-2967 but the object (String and CollationElementIterator) creations introduced
in DERBY-2967 can be cut down by following Knut's simple solution. I am copying that solution
from DERBY-2967. We should implement that solution to improve the performance of LIKE for
territory based characters.
> **********copied from DERBY-2967**********************************************************
> Another simple way to cut down the string allocations... I think you could express iapi.types.Like:checkEquality()
like this: 
>     if (val[vLoc] == pat[pLoc]) { 
>         // same character, so two strings consisting of this 
>         // single character must be equal regardless of territory 
>         return true; 
>     } else if (collator == null) { 
>         // not same character, must be unequal in UCS_BASIC 
>         return false; 
>     } 
>     String s1 = new String(val, vLoc, 1); 
>     String s1 = new String(pat, pLoc, 1); 
>     return collator.compare(s1, s2) == 0; 
> This would only allocate new objects if the characters are not equal. 
> ******************************************************************************************

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message