RE: Oracle ref cursors
Generic cursor support with the ability to
map it using a result map would be nice too. I thought the whole point was to
avoid touching the result set.
From: Clinton Begin
[mailto:[EMAIL PROTECTED]
Sent: Thursday, February 09, 2006
9:47 PM
To: dev@ibatis.apache.org;
[EMAIL PROTECTED]
Subject: Re: Oracle ref cursors
Hmmm...ok. Here's what I'd like to see in a solution:
* No dependency upon Oracle (like you've said).
* ResultSet types should be supported in both OUT parameters, as well as
result set columns (ick).
* The regular result set returned by a select statement or procedure
should not be compromised.
So conceivably I should be able to do something like this:
---
resultMap
result ... jdbcType=ResultSet
useResultMap=.../
/resultMap
parameterMap
parameter jdbcType=ResultSet
useResultMap=.../
/parameterMap
proc id=blah ...
...
/
List list = sqlMap.queryForList(blah, myParam);
---
In this case, I may have dealt with 3 result maps. One to deal with the OUT
param, one to deal with result sets nested in columns, and of course the normal
one returned from a call to .executeQuery().
Note that the XML attribute resultMap is already used for
result tags, so I called the attribute
useResultMapbut perhaps there's a better name that's not too
long (e.g. cursorResultMap)?
Thoughts?
Clinton
On 2/9/06, Clinton
Begin
[EMAIL PROTECTED] wrote:
Yep. I agree on the need. Just being cautious about the
implementation.
Cheers,
Clinton
On 2/9/06, Sven
Boden
[EMAIL PROTECTED] wrote:
In case anyone is interested in having a look, I uploaded the patch to
the patch to the wiki,
http://opensource2.atlassian.com/confluence/oss/display/IBATIS/Oracle+REF+CURSOR+Solutions
We may need to think some other things over, but a lot of people seem to
need/want something in iBATIS to convert ResultSets from stored
procedures to maps.
Sven
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 [EMAIL PROTECTED] 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
FW: specify typehandler for byte[]
Got no closure on this issue on the users
list. I do believe it is a bug but I couldnt locate it in the source
myself, since Im not familiar with it. If you guys concur, I can open a
JIRA issue.
From: March, Andres
[mailto:[EMAIL PROTECTED]
Sent: Monday, January 09, 2006
9:30 AM
To: user-java@ibatis.apache.org
Subject: RE: specify typehandler
for byte[]
I want to emphasize that this works when I
specify the handler per column in the sqlmap parameter map because I
dont need to specify the javaType there. But I want to specify it
globally, so I dont have to create parameterMaps and typeHandler declarations
for every column.
My class has a property like this:
Private ds byte[ ]
The db tables are like this:
CREATE TABLE bugs.x86_seg_reg
(
id int8 NOT NULL DEFAULT
nextval('x86_seg_reg_id_seq'::regclass),
ds numeric(16) NOT NULL,
es numeric(16) NOT NULL,
fs numeric(16) NOT NULL,
gs numeric(16) NOT NULL,
CONSTRAINT x86_seg_reg_pkey PRIMARY
KEY (id)
)
The sql created from the default type
handler does setBytes() but Postgres interprets that as a bytea column
type. So I created my own type handler:
typeHandler javaType=byte[] jdbcType=NUMERIC callback=com.soe.freerealms.dao.ibatis.ByteArrayBigDecimalTypeHandler/
So it will do a setBigDecimal instead:
/*
* (non-Javadoc)
*
* @see com.ibatis.sqlmap.engine.type.TypeHandler#setParameter(java.sql.PreparedStatement,
* int, java.lang.Object, java.lang.String)
*/
public void setParameter(PreparedStatement ps, int i, Object parameter,
String jdbcType) throws SQLException {
BigDecimal decParam = new BigDecimal(new BigInteger(1,(byte[]) parameter));
ps.setBigDecimal(i, decParam);
}
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Sunday, January 08, 2006
6:50 PM
To: user-java@ibatis.apache.org
Subject: Re: specify typehandler
for byte[]
Andres,
I guess I am confused as to what you are trying to do. Can you
give an example of the data?
Nathan
On Jan 6, 2006, at 7:22 PM, March, Andres wrote:
Im trying to write
the bytes to a numeric column not a binary one. The default one uses
setBytes(). I need to do setBigDecimal().
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent:
Friday, January 06, 2006 6:19 PM
To: user-java@ibatis.apache.org
Subject:
Re: specify typehandler for byte[]
why is thedefault not good enough
for you?
On Jan 6, 2006, at 6:51 PM, March, Andres
wrote:
Well, I learned something
new today the internal representation of class names. This
mapping does not fail like before:
typeHandler =jdbcTypeNUMERIC =javaTypebyte[] =callbackcom.soe.freerealms.dao.ibatis.ByteArrayBigDecimalTypeHandler
But I get an error because iBatis is
doing a class.forName() on the javaType attribute. Is there any way to do
this mapping?
-
Platform - Apps Engineering
desk: 858.577.3373
RE: specify typehandler for byte[]
This is the javaType that works in the sqlmap
but not in the sqlconfig [B
I will try [Ljava.lang.Byte
Guess I forwarded an incomplete thread:
Well, I learned something new today the
internal representation of class names. This mapping does not fail like
before:
typeHandler javaType=[B jdbcType=NUMERIC callback=com.soe.freerealms.dao.ibatis.ByteArrayBigDecimalTypeHandler/
But it is not being called for my byte[]
properties. The existing byte array type handler is instead. Any
clues as how to fix this?
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 19, 2006
11:56 AM
To: dev@ibatis.apache.org
Cc: March, Andres
Subject: Re: specify typehandler
for byte[]
Andres,
I think you might have your javaType attribute wrong. Can you try
[Ljava.lang.Byte and let me know if that works for you.
Nathan
On Jan 19, 2006, at 11:45 AM, March, Andres wrote:
Got no closure on this issue on the
users list. I do believe it is a bug but I couldnt locate it in the
source myself, since Im not familiar with it. If you guys concur, I can
open a JIRA issue.
From: March, Andres [mailto:[EMAIL PROTECTED]]
Sent:
Monday, January 09, 2006 9:30 AM
To: user-java@ibatis.apache.org
Subject:
RE: specify typehandler for byte[]
I want to emphasize that
this works when I specify the handler per column in the sqlmap parameter map
because I dont need to specify the javaType there. But I want to specify
it globally, so I dont have to create parameterMaps and typeHandler
declarations for every column.
My class has a property
like this:
Private ds byte[ ]
The db tables are like
this:
CREATE TABLE
bugs.x86_seg_reg
(
id int8 NOT NULL
DEFAULT nextval('x86_seg_reg_id_seq'::regclass),
ds numeric(16) NOT
NULL,
es numeric(16) NOT
NULL,
fs numeric(16) NOT
NULL,
gs numeric(16) NOT
NULL,
CONSTRAINT
x86_seg_reg_pkey PRIMARY KEY (id)
)
The sql created from the
default type handler does setBytes() but Postgres interprets that as a bytea
column type. So I created my own type handler:
typeHandler =jdbcTypeNUMERIC
=/
typeHandler jdbcType=javaType=com.soe.freerealms.dao.ibatis.ByteArrayBigDecimalTypeHandler
Platform
- Apps Engineering
