Re: ibatis 2.1.7 build #597 value object problem

thanks a lot! 2008/4/21, Clinton Begin <[EMAIL PROTECTED]>: > > Two solutions to this one: > > 1) Turn lazy loading off > > 2) Use a join mapping (which will be faster anyway) << preferred. > > This is a known limitation of the lazy loader, but something we could > probably fix too. > > Clinton

Re: iBatis-362 - Caching broken for stored procs

You must be an Oracle user... :-) CallableStatements can return ResultSets just like any PreparedStatement can. The difference is that CallableStatements can also have results of their own, which is the more traditional "output parameter" from the JDBC API perspective. It is these results that a

Re: iBatis-362 - Caching broken for stored procs

Yes, that will work, as long as it's not an out param. Clinton On Tue, Apr 22, 2008 at 3:33 PM, <[EMAIL PROTECTED]> wrote: > > Caching regular results is all that I am interested in. So does this > currently work? > > I have the following defined: > >"true"> > > > > > > And here

RE: iBatis-362 - Caching broken for stored procs

Thanks for the response, Clint. I'm a little confused about the difference between regular results and OUT results. I assume the return result of a stored function is always an OUT parameter. My current fix is to use LRUMap from commons-collections, but what I'd really like is manual access

Re: iBatis-362 - Caching broken for stored procs

Caching regular results is all that I am interested in. So does this currently work? I have the following defined: And here is where I use it: So am I to understand that this is all I should need for it to work with a procedure? Thanks for the help Clinton... "Cl

Re: iBatis-362 - Caching broken for stored procs

The bug is actually invalid. The reason it "worked" in 2.1.5 is that procs weren't cached at all. In 2.2.0+ proc statements were cached, but there's no way to cache output parameters, as you're passing the object in (so we can't cache it). We could build something in to mock the parameter object

Re: element

I have fixed the problem by not specifying jdbcType in the configuration. Why is this necessary? The type is CLOB. On Tue, 2008-04-22 at 11:38 -0400, Kenny Pearce wrote: > Hi, > I've been trying to configure TypeHandlerCallback implementations using > the element in for some time, and I ha

RE: iBatis-362 - Caching broken for stored procs

I have observed that batch execution of stored procs pretty much takes the same amount of time as executing the procedure in a loop. Warm Regards, Sundar Sankarnarayanan Software Engineer @University of Phoenix From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECT

Re: iBatis-362 - Caching broken for stored procs

Is this true? Caching does not work with stored procedures? Is there a work around or is a patch expected? Thanks... Chris "Jason Bennett" <[EMAIL PROTECTED]> 04/17/2008 12:32 PM Please respond to user-java@ibatis.apache.org To cc Subject iBatis-362 - Caching broken for stored procs

element

Hi, I've been trying to configure TypeHandlerCallback implementations using the element in for some time, and I have never been able to get it to work. I have usually worked around it by specifying the type handler for the individual parameter or result, but I've come across a case where