[jira] Commented: (DERBY-3136) Cut down on object creations in LIKE clause implementation of territory based characters.

["Mamta A. Satoor (JIRA)" <ji...@apache.org>]

    [ 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

DERBY-3136

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 string.

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: 10.3.1.5, 10.4.0.0
>            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.