possible feature of jdk1.7

Closure http://expertstech.blogspot.com/2008/09/closures-for-java.html -- View this message in context: http://www.nabble.com/possible-feature-of-jdk1.7-tp19301595p19301595.html Sent from the iBATIS - User - Java mailing list archive at Nabble.com.

Re: New iBATIS build on Maven central repository.

Yes, I'm using it in PROD. But I'm afraid that the artifact is not available in a central repo. Maybe you should ask on the dev-list if anybody can trigger the upload to ibiblio. Regards Kai --- Original Nachricht --- Absender: Zhubin Salehi Datum: 03.09.2008 21:47 I was wondering if anyone u

Re: New iBATIS build on Maven central repository.

I was wondering if anyone uses version 2.3.3 in a production environment. Is there a way to put this build on Maven central repo? Zhubin Salehi wrote: > > I was wondering if the new build are going to be available on Maven > central repository EVER! Any news? > -- View this message in contex

Re: Dealing with large CLOBs and Oracle 10g

Wasn't trying to be flippant with the "google it" ;) Was out of the office. Java Strings can only hold 32k. The 10g driver gets around that but you definitely need to use the 10g driver. You didnt indicate which one you're using. Jason On Sep 3, 2008, at 12:50 PM, Jason Kratz wrote:

Re: Dealing with large CLOBs and Oracle 10g

iBATIS' Clob type handler is trying to convert the entire Clob to a String - I guess this is where the issue lies. If this can't be fixed through the setting of some driver property, then I think you'll have to write and register a new type handler, then carry around the Clob instead of the String

Re: GroupBy issues (multiple child lists, Postgres limit/offset)

Thanks guys, that's helpful. On Wed, Sep 3, 2008 at 9:59 AM, Clinton Begin <[EMAIL PROTECTED]>wrote: > Sorry, you're right, I didn't read your SQL fully. :-) I just saw > LIMIT 100 and was like N :-) > > Your approach is absolutely perfect. > > Clinton > > On Wed, Sep 3, 2008 at 10:

Re: Dealing with large CLOBs and Oracle 10g

Google it. There is support in the 10g driver for this but requires some special setup. Jason Sent from my iPhone On Sep 3, 2008, at 12:24 PM, Paul Sanders <[EMAIL PROTECTED]> wrote: We recently upgraded our databases from 9i to 10g and now we are running into a problem when fetching ro

Dealing with large CLOBs and Oracle 10g

We recently upgraded our databases from 9i to 10g and now we are running into a problem when fetching rows containing large CLOBs. Here's a snippet of our resultMap: OLDDATA and NEWDATA are both defined as CLOB in the table. Queries that used to work before now fail with an O

Re: GroupBy issues (multiple child lists, Postgres limit/offset)

Sorry, you're right, I didn't read your SQL fully. :-) I just saw LIMIT 100 and was like N :-) Your approach is absolutely perfect. Clinton On Wed, Sep 3, 2008 at 10:04 AM, Kai Grabfelder <[EMAIL PROTECTED]> wrote: > Clinton, > > how can I get inconsistent data with my approach? I

Re: GroupBy issues (multiple child lists, Postgres limit/offset)

Clinton, how can I get inconsistent data with my approach? I think we misunderstood each other ;-) My usecase was the following (and I think it was also the usecase of the OP): Book --< Author = A book can have multiple authors. Now I want to select the first 100 books, sorted alpabetically,

Re: GroupBy issues (multiple child lists, Postgres limit/offset)

But Kai, using that approach, you will get an inconsistent view of the records. Some child records will be missing. the way that ORMs do this is with two queries... select distinct P.ID from PERSON P, DEPARTMENT D LIMIT 100 select * from PERSON P, DEPARTMENT D . and P.ID in (23, 45, 6

Re: GroupBy issues (multiple child lists, Postgres limit/offset)

Hi Reuben, regarding your first problem: Have you tried to give a comma separated list for the groupBy criteria? Just an idea, until now I was only grouping for one element not multiple ones as it can get quite expensive to do n+1 joins on several tables on the database level. regarding your

Re: GroupBy issues (multiple child lists, Postgres limit/offset)

The second problem is a limitation that we cannot do anything about, which makes the rest of the conversation somewhat FYI only. The first problem does sound like a bug, but strangely I have unit tests confirming that this works. I'll try writing a few more to see if I can reproduce the problem.

Fwd: GroupBy issues (multiple child lists, Postgres limit/offset)

Anybody have any feedback on this? Thanks Reuben -- Forwarded message -- From: Reuben Firmin <[EMAIL PROTECTED]> Date: Tue, Sep 2, 2008 at 11:26 AM Subject: GroupBy issues (multiple child lists, Postgres limit/offset) To: user-java@ibatis.apache.org We are trying to resolve some

Re: selectKey twice

hi Larry, thanks for your post. I use DB2 and at this time it's a single threaded system. But I don't understand why ibatis throws no exception and accepts this mapping. David Larry Meadors wrote: > > No, I think it only runs one of them...but are you really generating > two new keys? > > I

Re: selectKey twice

No, I think it only runs one of them...but are you really generating two new keys? If you are, don't do it this way unless it is and will always be a single threaded system, and only if your database can't do auto-incrementing ids - what database are you using? Larry On Wed, Sep 3, 2008 at 2:52

selectKey twice

Hello, i have a problem with an insert. I need two generated ids to avoid an update after the insert. My Question is: Is it possible to use two selectKey Tags. Ibatis throws no exception, instead I get the correct id at the first selectKey and 0 at the second selectKey.