![]() |
Using Cloudscape's Java Extensions
|
Reference Manual |
SQL-J and Java Type CorrespondenceBuilt-in types have corresponding Java data types at compile time. This correspondence is pertinent at compile time, when Cloudscape validates data types for inserts, joins, unions, and any statement in which two values must be compared somehow. A PreparedStatement is compiled when it is prepared; a Statement is compiled when it is executed. Values associated with a column of the built-in type automatically map, when an SQL-J statement is compiled, to values of the corresponding Java data type during compilation. For example, an insert into a column of type INTEGER expects a value of an INTEGER data type. Because the INTEGER data type has a compile-time corresponding Java data type of java.lang.Integer, Cloudscape also accepts a value of java.lang.Integer at compile time.
-- the compiler determines that the data type of the Since built-in types do not correspond to Java primitives at compile time, you cannot construct a Java primitive with a simple literal within the context of an SQL-J statement. For example, the literal 1 is an INTEGER value (which corresponds to a java.lang.Integer). Because of the compile-time correspondences, you can insert a value of a built-in type into a column of its corresponding Java class, and vice versa. In addition, SQL-J expressions that become method receivers (an expression to which the method is applied) and SQL-J expressions that are used as parameter values in a method are also mapped to Java types. In the following example, the expression (1+3) is the method receiver and 35 is a parameter. Both expressions, initially SQL-J INT types, are converted to java.lang.Integer when Cloudscape executes the method. In SQL-J statements, Cloudscape converts the return values of invoked Java methods and accessed fields of Java objects or classes to SQL-J values, except when the value is used as a receiver or parameter to another method. In that case, the value remains a Java value. Although built-in SQL-J types map to Java classes, not Java primitives, many Java methods use primitive types as parameters or return values. For that reason, if on the first attempt to resolve a method Cloudscape does not find a match for the method with what it thinks is the given signature, Cloudscape converts all SQL-J numeric types and BOOLEANs to their corresponding Java primitive types. (This conversion is all-or-nothing.) Consider the following example: VALUES NEW java.lang.Integer(1) On the first attempt, Cloudscape looks for a method with a java.lang.Integer parameter (because that is the type that corresponds to the SQL-J INT expression 1) and fails. On the second attempt, Cloudscape looks for a method with an int parameter and succeeds. For details about conversion of SQL-J types to Java types, see SQL-J and Java Type Correspondence in the Cloudscape Reference Manual. Because of the way Cloudscape maps SQL-J types to Java object types, Cloudscape may not be able to find a method with the appropriate signature under certain circumstances. When you use a dynamic parameter as a method parameter, for example, you may have to use an explicit CAST when invoking such Java methods within Cloudscape. For more information, see SQL-J and Java Type Correspondence and Dynamic Parameters of the Cloudscape Reference Manual. |
|
![]() Cloudscape Version 3.6 For information about Cloudscape technical support, go to: www.cloudscape.com/support/.Copyright © 1998, 1999, 2000 Informix Software, Inc. All rights reserved. |