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)
|
Список | 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 по дате отправления: