|
replacing my earlier comment due to typo.
I think the wrapper function for getBigDecimal by columnname, getBigDecimalStringFromName, should take a columnname parameter rather than getting it in the method. I think it would be good to have a class comment with the summary of the handling of BigDemcimal values in J2ME and an explanation of how tests that use BigDecimal values should be written so that they work with J2ME. I am not really comfortable with the mock up of data conversion exceptions for J2ME but don't really have a better idea #:). Need to check the types listed in canConvertToDecimal. I think some of them are not quite right. This patch (derby_453_outparams_patch1.diff) changes tests.
* It enables the tests which use procedures in outparams.java to run in J2ME/CDC/FP. The following tests have been enabled: - lang/lang/outparams.java - jdbcapi/batchUpdate.java - jdbcapi/StmtCloseFunTest.java * It disables the test lang/dbjar.sql from J2ME/FP because it uses java.sql.Driver. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to outparams.java: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * The methods 'takesBigDecimal' and 'returnsBigDecimal' are moved from outparams.java to a new class outparams30.java. These methods use java.Math.BigDecimal class which is not available in J2ME. This separation is needed because Connection.prepareCall looks at all the public methods available in the specified class. If the class has any public method using BigDecimal, it will fail in J2ME. * For procedure names, outparams class will be used for J2ME and outparams30 for non-J2ME. * Variables HAVE_BIGDECIMAL and CLASS_NAME are added to outparams.java. Depending on the availability of BigDecimal class in the JVM, CLASS_NAME is initialized to outparams or outparams30. CLASS_NAME is used in the create procedure SQL instead of "org.apache.derbyTesting.functionTests.tests.lang.outparams.". * The content of the arrays 'outputMethods' and 'returnMethods' are also decided based on value of HAVE_BIGDECIMAL. For J2ME, takesBigDecimal and returnsBigDecimal are removed from these arrays. To minimize changes to the master file, the order of these arrays is kept same. An if/else loop is used to determine which array will be used. * callSetMethod, callSetObject and callGetMethod are changed to use wrapper methods in BigDecimalHandler class. An additional parameter 'int paramType' is passed to callGetMethod. This is needed because ParameterMetaData is not available in JSR19. A new array 'paramJDBCType' with the JDBC types (java.sql.Types) for the corresponding methods is used to get the param type for a method. When creating this array, I noticed that outputMethods and returnMethods do not match. To make them match, a null value has been removed from outputMethods and outProcParam arrays. * testMisc method used returnsBigDecimal to check that a set cannot be called on an output param. This check is independent of the type of output param and so returnsString is used intstead. * test5116 method uses a procedure with nested connection, which uses java.sql.Driver. This is not available in JSR169. So this test is done only for non-JSR169 environments based on value of HAVE_DRIVER_CLASS. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to org.apache.derbyTesting.functionTests.util.BigDecimalHandler.java: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * Added wrappers for following methods: CallableStatement method getBigDecimal(int parameterIndex) PreparedStatement method setBigDecimal(int parameterIndex,BigDecimal x) PreparedStatement method setObject(int parameterIndex, Object x) * Fixed the type conversions and moved it to an array, which is used in the method canConvertToDecimal. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to master files: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * The master files for main and j9_13 are modified to use returnsBigDecimal instead of returnsString in output for testMisc method. On comparing the two master files, they are identical. I think the master file for j9_13 can be removed. I have not done it in this patch. Is it okay to do this? * Added a master file for j9_foundation. This is needed because of the following: - takesBigDecimal and returnsBigDecimal methods are not in outputMethods/returnMehtods. - The exception strings for type conversion and invalid character format are different because of use of wrapper methods. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to <testname>_app.properties: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * Removed excludes for J2ME for following tests: - lang/outparams.java - jdbcapi/batchUpdate.java - jdbcapi/StmtCloseFunTest.java * Added exclude for J2ME to following test: - lang/dbjar.sql - This test failed when derbyall was run with J2ME. This is a new test and it uses java.sql.Driver. Hence excluded. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to tests which use procedures in outparams.java -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- * jdbcapi/batchUpdate.java and jdbcapi/StmtCloseFunTest.java are modified to use outparams/outparams30 depending on value of HAVE_BIG_DECIMAL. * jdbcapi/StmtCloseFunTest.java was using a deprecated constructor for java.sql.Date, which is not available in JSR169. So the constructor java.sql.Date(long) is used instead. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Tests Run -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This patch changes tests only. I had run derbyall in J2SE and J2ME. 1 expected failure in J2ME. But I made few changes before submitting this patch. After the changes, I ran the individual tests successfully. Please review/commit this patch. NOTE: JIRA did not give me an option to add comments when I attached the patch files. So adding it as a separate comment. I have a question about the patch.
In BigDecimalHandler, the string representation uses setDouble(). Wouldn't setString would be more exact? For example in setBigDecimalString I see. case STRING_REPRESENTATION: ps.setDouble(parameterIndex,new Double(bdString).doubleValue()); break; As you said, setString would be more exact. Also, the method setBigDecimalString takes a String parameter and it would be better to use it directly. I will change setDouble to setString and submit another patch.
I am re-submitting the patch as derby_453_outparams_patch2.diff. In the new patch, I commented out java.sql.Types.BOOLEAN since it is not available in jdk13.
I tried changing setString to setDouble in BigDecimalHandler but then, the testcase failed for takesShortPrimitive procedure. It gave a "Invalid character string format exception for SMALLINT". This is because the value used is "666.666". If a String which can be converted to short is used (like "666"), this would not be a problem. On the other hand, if setDouble is used, the conversion to short is taken care of. So I am continuing to use setDouble. I agree this will compromise the precision of values. But since this testcase is not dependent on precision, I think it should be okay. If you think of other reasons for this change, please share them. setDouble is not acceptable. DECIMAL types are precise values, whereas doubles are imprecise. If the user/application wants to convert DECIMAL types to imprecise types (double & float) that''s fine, but test code should be ensuring an precise type remains precise.
In that case, I will change to setString. But I am little confused as to how I should proceed. I see two ways to handle the test:
1. In callSetObject in outparams.java, I can continue to pass "666.666" to setBigDecimalString. This will give error in setString for short primitive type because the String passed is not convertible to short. This is the expected behaviour. I can update the master file for j9_foundation accordingly. 2. I can pass "666" to setBigDecimalString. This will work with all the object types for which conversion is valid. But we are not testing a decimal value. Please let me know which of these is a good approach or if there is another way of doing this. Submitting another patch derby_453_outparams_patch3.diff. This patch uses setString instead of setDouble in the wrapper method. I have changed the master file for j9_foundation accordingly.
Deepa and I spoke briefly about this patch. Here's the summary of my comments.
- There a couple of uses of Double still that can be removed 1) in setObject it is used. 2) new Double() is used in getBigDecimalString() to verify that the value is a number and an exception thrown that matches the server internal message that is thrown if you do getBigDecimal on a non numeric value. This may not work in all cases and seems a bit confusing. Maybe better to just let the caller deal with the value as returned from getString I noted that StmtCloseFunTest.java has been changed to use long literal values in the Date Constructor. (The test was using a deprecated constructor.) Deepa said this was because Aparently J2ME doesn't have a Calendar class. so it's not clear how to construct the date except by this method which other tests use. A small change to the above comment. StmtCloseFunTest.java is changed to use the constructor java.sql.Date(long) because the deprecated constructor (Date(int year, int month, int day) ) is not available in JSR169.
Submitting another patch derby_453_outparams_patch4.diff for Kathey's comments.
Attaching a patch for test jdbcapi/parameterMetaDataJdbc30.java. Changed the test to use returnsBigDecimal method from outparams30.java
The patches for the above tests have been committed. 12 tests in the list now run with j2me. 3 tests (functions.sql, procedure.java and triggerRefClause.sql) are still excluded with comments why they cannot run in j2me/fp.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Minor
Create a test wrapper to run tests using BigDecimal in J2ME/CDC/Foundation
1. Added a new class ResultSet_BD, which provides wrappers for the following ResultSet methods:
getBigDecimal(int columnIndex) ~ getBigDecimalString(ResultSet rs, int columnIndex)
getBigDecimal(String columnName) ~ getBigDecimalStringFromName(ResultSet rs, int columnIndex)
getObject(int columnIndex) ~ getObjectString(ResultSet rs, int columnIndex)
getObject(String columnName) ~ getObjectStringFromName(ResultSet rs, int columnIndex)
2 . Modified resultset.java to call methods in ResultSet_BD instead of the above ResultSet methods.
3. resultset.java was using the following deprecated ResultSet methods:
getBigDecimal(int columnIndex, int scale)
getBigDecimal(String columnName, int scale)
In ResultSet_BD, getBigDecimal(int columnIndex) and getBigDecimal(String columnName) are called instead of the deprecated methods. The master file resultset.out has been changed to match this.
4. The exclude flag "runwithfoundation=false" has been removed from resultset_app.properties
I have tested this patch by running resultset.java with Sun Java 1.4.2 and IBM WCTME 5.7 Foundation profile.