You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mamta A. Satoor (JIRA)" <ji...@apache.org> on 2008/01/11 07:09:34 UTC
[jira] Created: (DERBY-3315) Should UCS_BASIC character types have
to look at collation elements when dealing with escape character in the
LIKE clause?
Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?
--------------------------------------------------------------------------------------------------------------------------
Key: DERBY-3315
URL: https://issues.apache.org/jira/browse/DERBY-3315
Project: Derby
Issue Type: Task
Components: JDBC
Affects Versions: 10.3.2.1, 10.3.1.4, 10.4.0.0
Reporter: Mamta A. Satoor
Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for non-national/non-collation sensitive character types ie for UCS_BASIC character types and the code looks as follows
// Make sure we fail for both varchar an nvarchar
// for multiple collation characters.
SQLChar escapeSQLChar = (SQLChar) escape;
int[] escapeIntArray = escapeSQLChar.getIntArray();
if (escapeIntArray != null && (escapeIntArray.length != 1))
{
throw StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new String (escapeSQLChar.getCharArray()));
}
It appears that we are trying to see if number of collation elements associated with escape character is more than 1 and if yes, then we throw exception. Seems like a code like above should be done for collation sensitive character types and not for UCS_BASIC character types. Interestingly, nothing like this is getting checked for national character datatypes.
This behavior was detected while working on DERBY-3302
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3315) Should UCS_BASIC character types
have to look at collation elements when dealing with escape character in
the LIKE clause?
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559617#action_12559617 ]
Mamta A. Satoor commented on DERBY-3315:
----------------------------------------
I have removed the code mentioned above while removing the disabled national character code. The changes went in as part of revision 612525 into trunk. I will port these changes into 10.3 too.
> Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3315
> URL: https://issues.apache.org/jira/browse/DERBY-3315
> Project: Derby
> Issue Type: Task
> Components: JDBC
> Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mamta A. Satoor
>
> Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for non-national/non-collation sensitive character types ie for UCS_BASIC character types and the code looks as follows
> // Make sure we fail for both varchar an nvarchar
> // for multiple collation characters.
> SQLChar escapeSQLChar = (SQLChar) escape;
> int[] escapeIntArray = escapeSQLChar.getIntArray();
> if (escapeIntArray != null && (escapeIntArray.length != 1))
> {
> throw StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new String (escapeSQLChar.getCharArray()));
> }
> It appears that we are trying to see if number of collation elements associated with escape character is more than 1 and if yes, then we throw exception. Seems like a code like above should be done for collation sensitive character types and not for UCS_BASIC character types. Interestingly, nothing like this is getting checked for national character datatypes.
> This behavior was detected while working on DERBY-3302
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3315) Should UCS_BASIC character types have
to look at collation elements when dealing with escape character in the
LIKE clause?
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor reassigned DERBY-3315:
--------------------------------------
Assignee: Mamta A. Satoor
> Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3315
> URL: https://issues.apache.org/jira/browse/DERBY-3315
> Project: Derby
> Issue Type: Task
> Components: JDBC
> Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mamta A. Satoor
>
> Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for non-national/non-collation sensitive character types ie for UCS_BASIC character types and the code looks as follows
> // Make sure we fail for both varchar an nvarchar
> // for multiple collation characters.
> SQLChar escapeSQLChar = (SQLChar) escape;
> int[] escapeIntArray = escapeSQLChar.getIntArray();
> if (escapeIntArray != null && (escapeIntArray.length != 1))
> {
> throw StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new String (escapeSQLChar.getCharArray()));
> }
> It appears that we are trying to see if number of collation elements associated with escape character is more than 1 and if yes, then we throw exception. Seems like a code like above should be done for collation sensitive character types and not for UCS_BASIC character types. Interestingly, nothing like this is getting checked for national character datatypes.
> This behavior was detected while working on DERBY-3302
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3315) Should UCS_BASIC character types have
to look at collation elements when dealing with escape character in the
LIKE clause?
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor resolved DERBY-3315.
------------------------------------
Resolution: Fixed
Fix Version/s: 10.4.0.0
10.3.2.2
Merged changes from trunk(612525) into 10.3 codeline(revision 612576).
> Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3315
> URL: https://issues.apache.org/jira/browse/DERBY-3315
> Project: Derby
> Issue Type: Task
> Components: JDBC
> Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mamta A. Satoor
> Fix For: 10.3.2.2, 10.4.0.0
>
>
> Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for non-national/non-collation sensitive character types ie for UCS_BASIC character types and the code looks as follows
> // Make sure we fail for both varchar an nvarchar
> // for multiple collation characters.
> SQLChar escapeSQLChar = (SQLChar) escape;
> int[] escapeIntArray = escapeSQLChar.getIntArray();
> if (escapeIntArray != null && (escapeIntArray.length != 1))
> {
> throw StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new String (escapeSQLChar.getCharArray()));
> }
> It appears that we are trying to see if number of collation elements associated with escape character is more than 1 and if yes, then we throw exception. Seems like a code like above should be done for collation sensitive character types and not for UCS_BASIC character types. Interestingly, nothing like this is getting checked for national character datatypes.
> This behavior was detected while working on DERBY-3302
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3315) Should UCS_BASIC character types
have to look at collation elements when dealing with escape character in
the LIKE clause?
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558014#action_12558014 ]
Daniel John Debrunner commented on DERBY-3315:
----------------------------------------------
I would say the check is just wrong. Why does the number of collation elements for an escape character need to be one?
The escape character is there to escape special characters, it has nothing to do with collation.
> Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3315
> URL: https://issues.apache.org/jira/browse/DERBY-3315
> Project: Derby
> Issue Type: Task
> Components: JDBC
> Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
> Reporter: Mamta A. Satoor
>
> Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for non-national/non-collation sensitive character types ie for UCS_BASIC character types and the code looks as follows
> // Make sure we fail for both varchar an nvarchar
> // for multiple collation characters.
> SQLChar escapeSQLChar = (SQLChar) escape;
> int[] escapeIntArray = escapeSQLChar.getIntArray();
> if (escapeIntArray != null && (escapeIntArray.length != 1))
> {
> throw StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new String (escapeSQLChar.getCharArray()));
> }
> It appears that we are trying to see if number of collation elements associated with escape character is more than 1 and if yes, then we throw exception. Seems like a code like above should be done for collation sensitive character types and not for UCS_BASIC character types. Interestingly, nothing like this is getting checked for national character datatypes.
> This behavior was detected while working on DERBY-3302
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.