Return-Path: 
 <dev-return-2388-apmail-ibatis-dev-archive=ibatis.apache.org@ibatis.apache.org>
Delivered-To: apmail-ibatis-dev-archive@www.apache.org
Received: (qmail 13140 invoked from network); 9 Feb 2006 22:12:02 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 9 Feb 2006 22:12:02 -0000
Received: (qmail 49053 invoked by uid 500); 9 Feb 2006 22:11:34 -0000
Delivered-To: apmail-ibatis-dev-archive@ibatis.apache.org
Received: (qmail 49008 invoked by uid 500); 9 Feb 2006 22:11:33 -0000
Mailing-List: contact dev-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@ibatis.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@ibatis.apache.org>
List-Post: <mailto:dev@ibatis.apache.org>
List-Id: <dev.ibatis.apache.org>
Reply-To: dev@ibatis.apache.org
Delivered-To: mailing list dev@ibatis.apache.org
Received: (qmail 48985 invoked by uid 99); 9 Feb 2006 22:11:33 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2006 14:11:33 -0800
X-ASF-Spam-Status: No, hits=0.3 required=10.0
	tests=MAILTO_TO_SPAM_ADDR
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [195.130.137.72] (HELO hoboe1bl1.telenet-ops.be)
 (195.130.137.72)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2006 14:11:32 -0800
Received: from localhost (localhost.localdomain [127.0.0.1])
	by hoboe1bl1.telenet-ops.be (Postfix) with SMTP id 188D2380CF
	for <dev@ibatis.apache.org>; Thu,  9 Feb 2006 23:11:10 +0100 (CET)
Received: from [213.118.77.102] (dD5764D66.access.telenet.be [213.118.77.102])
	by hoboe1bl1.telenet-ops.be (Postfix) with ESMTP id DE183380BF
	for <dev@ibatis.apache.org>; Thu,  9 Feb 2006 23:11:09 +0100 (CET)
Message-ID: <43EBBD72.8050804@pandora.be>
Date: Thu, 09 Feb 2006 23:08:50 +0100
From: Sven Boden <list123@pandora.be>
Reply-To: list123@pandora.be
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@ibatis.apache.org
Subject: Re: Oracle ref cursors
References: <43EBA652.4010707@pandora.be>
 <16178eb10602091345w1a8b3d15v7c54f967080ed4c4@mail.gmail.com>
In-Reply-To: <16178eb10602091345w1a8b3d15v7c54f967080ed4c4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N


There can be more than 1 out result sets, Michael's testcases on the 
wiki show that.

Will check the second bullet tomorrow, we can probably find a way around 
it.... it should also be just a resultset (but I vaguely remember some 
problems with it from past experiments).

Sven

Clinton Begin wrote:

>So the assumptions made here are:
>
>  * There can be only one out parameter of type ResultSet
>  * The default result set (possibly returned from a SELECT) is lost, as
>it's overidden by the ResultSet parameter.
>
>Seems a bit hackey, but I'm interested in everyone else's opinion.
>
>Clinton
>
>On 2/9/06, Sven Boden <list123@pandora.be> wrote:
>  
>
>>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
>>
>>
>>    
>>
>
>  
>