I've been playing a bit with Michael Fagan's patch for supporting
ResultMaps using Oracle ref cursors. Sometimes I'm also a bit fond of
pushing as much functionality as possible in Oracle procedures and only
exposing a ref cursor to the (C) applications.
The patch works but having ORACLECURSOR in the iBATIS code puts me a bit
off. So I made some small cosmetic changes... what about the following:
- Michael Fagan's patch (now already to be redone because of other
changes in 2.1.7)
- With following changes:
# Adding javaType="java.sql.ResultSet" to the parameterMap
<parameterMap id="single-rs" class="map" >
<parameter property="in1" jdbcType="int"
javaType="java.lang.Integer" mode="IN"/>
<parameter property="output1" jdbcType="ORACLECURSOR"
javaType="java.sql.ResultSet" mode="OUT"/>
</parameterMap>
# doing the ResultSet extraction as follows (hardcoding ResultSet
instead of ORACLECURSOR).
....
if (mapping.isOutputAllowed()) {
if (
"java.sql.ResultSet".equalsIgnoreCase(mapping.getJavaTypeName()) ) {
ResultSet rs = (ResultSet) cs.getObject( i + 1 );
....
# In the TypeHandlerFactory a shortcut "cursor" could be made for
java.sql.ResultSet
The above change would not put something "Oracle only" in iBATIS source
code, it would make the SQLMap still dependent on Oracle because of
ORACLECURSOR but I don't see this as a big problem (as soon as you use
SQL dialect in the SqlMaps you're also dependent upon a database).
As long as an other database supports a type for "cursor" it can use the
implementation above. Or is there something I'm missing, which could
come back to haunt us?
People using the current patch should then only add
"javaType="java.sql.ResultSet"" to their maps.
Regards,
Sven Boden
