db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3034) Address testing todo items in CollationTest.java
Date Wed, 29 Aug 2007 23:58:30 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kathey Marsden updated DERBY-3034:
----------------------------------

    Attachment: derby-3034_stat.txt
                derby-3034_diff.txt

The attached patch addresses the cases outlined in the todo testing except for import which
seems related to importing via VTI.  That will have to wait for VTI's to be implemented.

The patch also has a bit of reorganization, moving the SQLTypes array from CastingTest to
SQLUtilities



> Address testing todo items in CollationTest.java
> ------------------------------------------------
>
>                 Key: DERBY-3034
>                 URL: https://issues.apache.org/jira/browse/DERBY-3034
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Test
>    Affects Versions: 10.4.0.0
>            Reporter: Kathey Marsden
>            Assignee: Kathey Marsden
>            Priority: Minor
>         Attachments: derby-3034_diff.txt, derby-3034_stat.txt
>
>
> CollationTest has the following todo test items that should be addressed.
> 	/*
> 	 * ToDo test cases
> 	 * 1)Use a parameter as cast operand and cast that to character type. The
> 	 * resultant type should get it's collation from the compilation schema
> 	 * 2)Test conditional if (NULLIF and CASE) with different datatypes to see
> 	 * how casting works. The compile node for this SQL construct seems to be
> 	 * dealing with lot of casting code (ConditionalNode)
> 	 * 3)When doing concatenation testing, check what happens if concatantion
> 	 * is between non-char types. This is because ConcatenationOperatorNode
> 	 * in compile package has following comment "If either the left or right 
> 	 * operands are non-string, non-bit types, then we generate an implicit 
> 	 * cast to VARCHAR."
> 	 * 4)Do testing with upper and lower
> 	 * 5)It looks like node for LIKE ESCAPE which is LikeEscapeOperatorNode
> 	 * also uses quite a bit of casting. Should include test for LIKE ESCAPE
> 	 * which will trigger the casting.
> 	 * 6)Binary arithmetic operators do casting if one of the operands is
> 	 * string and other is numeric. Test that combination
> 	 * 7)Looks like import utility does casting (in ColumnInfo class). See
> 	 * if any testing is required for that.
> 	 * 8)Do testing with UNION and use the results of UNION in collation
> 	 * comparison (if there is something like that possible. I didn't put too
> 	 * much thought into it but wanted to list here so we can do the required
> 	 * testing if needed).
> 	 */

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


Mime
View raw message