Re: JDBC gripe list (the autocommit subthread)

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: JDBC gripe list (the autocommit subthread)
Дата
Msg-id 4D945B75020000250003BFF6@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: JDBC gripe list (the autocommit subthread)  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: JDBC gripe list (the autocommit subthread)  (Quartz <quartz12h@yahoo.com>)
Список pgsql-jdbc
`Kevin Grittner <Kgrittn@wicourts.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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: "David Patricola"
Дата:
Сообщение: Re: SSL connection failure
Следующее
От: BozhkoKA
Дата:
Сообщение: Cannot open connection while insert much data.