Re: JDBC gripe list (the autocommit subthread)

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Quartz" <quartz12h(at)yahoo(dot)com>
Cc: <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC gripe list (the autocommit subthread)
Date: 2011-03-31 15:46:13
Message-ID: 4D945B75020000250003BFF6@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

`Kevin Grittner <Kgrittn(at)wicourts(dot)gov> wrote:

> There's an array in that exception class.

I'm coming around to the position that we shouldn't tinker with
autoCommit within the executeBatch method. I still think it would
be best for us to consistently bail out on the first failure, but if
autoCommit is on, we could build the BatchUpdateException using an
array of the length of the successfully completed statements. If
autoCommit is off, I'm not sure whether it would be better to leave
the updateCounts property null or use a zero length array; but
clearly no statements should be considered successful.

The API documentation does seem to suggest it should work that way.

The bad news is that this would be a behavior change, and could thus
break existing code for current PostgreSQL users. When that's the
case, we generally like to see a reasonable use case for the new
behavior even when it is standard. So far we have a rather
hand-wavy assertion that it would be useful for logging and "an
infinite number of" other uses. It would probably help sway the
community if there was a more concrete explanation of why this was
better than the alternatives for logging purposes, and to sketch out
one or two of the other infinite number of use cases.

-Kevin

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Quartz 2011-03-31 21:25:56 Re: JDBC gripe list (the autocommit subthread)
Previous Message David Patricola 2011-03-31 15:36:34 Re: SSL connection failure