Import/export fails for DECIMAL type in J2ME/Foundation

• Key: DERBY-452
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Deepa Remesh
• Reporter: Deepa Remesh
• Component/s: Tools
• Affects Version/s: 10.1.1.0, 10.2.1.6
• Fix Version/s: 10.1.2.1, 10.2.1.6

Description

Derby import/export tool has to be modified to work in J2ME/Foundation.

I tried running the testcase importExport.java and it fails with following exception:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Test importExport starting
testing non-existing data file
Data file not found: extinout/Z.dat
testing null data file
Data file cannot be null.
testing empty table
testing empty table with Delimited format
testing empty table import Field/Char Delimiters
PASS: setup complete
testing import/export with default options
FAIL: exception thrown:
ERROR 38000: The exception 'SQL Exception: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'.' was thrown while evaluating an expression.
ERROR 22005: An attempt was made to get a data value of type 'java.lang.Object' from a data value of type 'DECIMAL'.
Test importExport finished
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The exception is thrown because Derby system procedure for export calls getObject() on a DECIMAL type. This is not supported in J2ME/Foundation. Derby Embedded JSR 169 Functional Spec asks to use alternate JDBC getXXX and setXXX methods (like getString and setString) for DECIMAL type. I think the Derby import/export utility can be modified to call getString and setString for DECIMAL type when using J2ME/Foundation.

Comments

[Deepa Remesh]

This patch handles export of DECIMAL type in J2ME/Foundation.

The code snippet which was throwing the exception is below:
//convert resultset data to string array
public String[] getOneRowAtATime(ResultSet rs) throws Exception {
int columnCount = exportResultSetForObject.getColumnCount();

ResultSetMetaData rsm=rs.getMetaData();
if (rs.next()){
String[] rowObjects = new String[columnCount];
for (int colNum = 0; colNum < columnCount; colNum++) {
if (rs.getObject(colNum + 1) != null)
{
rowObjects[colNum]=rs.getString(colNum + 1);
}
}
return rowObjects;
}
     
In J2ME/Foundation, this was throwing an exception because getObject on DECIMAL types is not supported. I removed the call to getObject since it was a redundant check. getString internally checks for null values. The new code is below:
       //convert resultset data to string array
public String[] getOneRowAtATime(ResultSet rs) throws Exception {
int columnCount = exportResultSetForObject.getColumnCount();

ResultSetMetaData rsm=rs.getMetaData();
if (rs.next()){
String[] rowObjects = new String[columnCount];
for (int colNum = 0; colNum < columnCount; colNum++) {
rowObjects[colNum]=rs.getString(colNum + 1);
}
return rowObjects;
}
     
The following tests now pass in J2ME/FP. I have removed the excludes for them:
tools/importExport.java
tools/importExportThruIJ.sql
tools/ieptests.sql

Ran derbyall with Sun Java 1.4.2 and IBM WCTME 5.7 Foundation Profile. One testcase failed in the latter. The failure is not related to this change.
     
Please review this patch and commit it.

Thanks,
Deepa

[Daniel John Debrunner]

Committed revision 219259.

[Deepa Remesh]

This patch can be applied to 10.1 branch also.

Committed revision 265639

[Kathey Marsden]

Fixed in 10.1 branch with revision 265639.

[Deepa Remesh]

reopening to fix fix version