Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42002813.8030108@debrunners.com>
Date: Tue, 01 Feb 2005 17:08:35 -0800
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: derby-dev <derby-dev@db.apache.org>
Subject: setting BigDecimal changes (svn 149467)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


For J2ME I needed to remove BigDecimal as a referenced class from most
of the code, this is the description for how this is handled for setting
DECIMAL values from BigDecimal. svn revision 149467.

The DataValueDescriptor and specific type interfaces such as
StringDataValue had setValue() methods that took a BigDecimal and other
implementations of Number, such as Integer etc.

The ones that had parameter types that were implementations of Number
exception BigDecimal I removed as they are legacy code, now such types
are explictly handled in PreparedStatement.setObject.

Then I created two set methods that take a Number as a parameter.

DataValueDescriptor.setBigDecimal(Number) is used where the application,
through JDBC (PreparedStatatement.setBigDecimal and others), passes in a
BigDecimal and the destination SQL type can be anything. The
implementation of this method for the various data types needs to ensure
that the resulting value is in range, e.g. for INTEGER (SQLInteger) the
value should fit in the range of a Java primitive int. Calling
Number.intValue() is not sufficient because that method silently
truncates. Though for REAL and DOUBLE the Number.floatValue() and
doubleValue() methods are sufficient because an out of range value is
converted to infinity which is then rejected by the Derby implementation
class.

NumberDataValue.setValue(Number) is used when the source Java type is
guaranteed to match the destination SQL type, e.g. java.lang.Integer for
SMALLINT and INTEGER, java.lang.Float for REAL etc. This occurs during
procedure or function calls and in some internally generated code. In
this case there is no requirement for range checking since the value of
the Java type cannot exceed the value of the SQL type.

The two methods could be combined into one, but I wanted to ensure that
function return types and procedure out/inout parameters setting were
optimized.

One tricky issue with Derby for code in the types area and the execution
area is that it is called "indirectly" through the generated code. Thus
changes to a method signature may require other changes that will not be
caught by the javac compiler. E.g. typically a change in a parameter
type will be handled by the javac compiler, either by upcasting
correctly (e.g. Integer to Number), or by throwing a compile error,
forcing you, the developer, to fix the code. However with generated code
errors will not be discovered until you run the tests, where some sanity
checks exist to check the generated method signature, or even the java
byte code verifier will handle the error, or maybe an abstract method
error. Apart from knowing the code, you can search for potential
generated calls to a method by

- - searching the source for the method name with quotes, e.g. "setValue"
- - searching for the defining class name in quotes
"org.apache.derby.iapi.types.NumberDataValue"
- - Searching for use of the class name constant, if it exists, e.g.
ClassName.NumberDataValue

It is important to remember that most, if not all, of the generated code
calls methods through the interface, ie. the internal api classes, and
not the implementation classes.


Similar changes will be needed for getting BigDecimal values out of
Derby's datatypes, that it next. Following that would be the split of
SQLDecimal into two classes, a base class and a BigDecimal
implementation with a J2ME one to follow.

Dan.

M    iapi/types/BooleanDataValue.java
M    iapi/types/DataType.java
M    iapi/types/DataValueDescriptor.java
M    iapi/types/DataValueFactory.java
M    iapi/types/DataValueFactoryImpl.java
M    iapi/types/NumberDataType.java
M    iapi/types/NumberDataValue.java
M    iapi/types/SQLBoolean.java
M    iapi/types/SQLChar.java
M    iapi/types/SQLClob.java
M    iapi/types/SQLDecimal.java
M    iapi/types/SQLDouble.java
M    iapi/types/SQLLongint.java
M    iapi/types/SQLReal.java
M    iapi/types/StringDataValue.java
M    iapi/types/UserType.java
M    impl/jdbc/EmbedPreparedStatement20.java
M    impl/sql/compile/BaseTypeCompiler.java
M    impl/sql/compile/BitTypeCompiler.java
M    impl/sql/compile/CharTypeCompiler.java
M    impl/sql/compile/NumericTypeCompiler.java
M    impl/sql/compile/StaticMethodCallNode.java
M    impl/sql/compile/UserDefinedTypeCompiler.java


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCACgTIv0S4qsbfuQRAkTmAJ9sla4l5Vp1gXQM53sAB+a0hEpcmACeOFyQ
P8JSiT8U6zGxgc6vc1RT+qU=
=zPwq
-----END PGP SIGNATURE-----