Re: [JDBC] JDBC Statement.executeBatch patch
Patch applied and files added. Thanks. > Attached is a patch for current CVS, consisting of a cvs diff -c > for the changed files and a few new files: > - test/jdbc2/BatchExecuteTest.java > - util/MessageTranslator.java > - jdbc2/PBatchUpdateException.java > > As an aside, is this the best way to submit a patch consisting > of both changed and new files? Or is there a smarter cvs command > which gets them all in one patch file? > > This patch fixes batch processing in the JDBC driver to be > JDBC-2 compliant. Specifically, the changes introduced by this > patch are: > > 1) Statement.executeBatch() no longer commits or rolls back a > transaction, as this is not prescribed by the JDBC spec. Its up > to the application to disable autocommit and to commit or > rollback the transaction. Where JDBC talks about "executing the > statements as a unit", it means executing the statements in one > round trip to the backend for better performance, it does not > mean executing the statements in a transaction. > > 2) Statement.executeBatch() now throws a BatchUpdateException() > as required by the JDBC spec. The significance of this is that > the receiver of the exception gets the updateCounts of the > commands that succeeded before the error occurred. In order for > the messages to be translatable, java.sql.BatchUpdateException > is extended by org.postgresql.jdbc2.PBatchUpdateException() and > the localization code is factored out from > org.postgresql.util.PSQLException to a separate singleton class > org.postgresql.util.MessageTranslator. > > 3) When there is no batch or there are 0 statements in the batch > when Statement.executeBatch() is called, do not throw an > SQLException, but silently do nothing and return an update count > array of length 0. The JDBC spec says "Throws an SQLException if > the driver does not support batch statements", which is clearly > not the case. See testExecuteEmptyBatch() in > BatchExecuteTest.java for an example. The message > postgresql.stat.batch.empty is removed from the language > specific properties files. > > 4) When Statement.executeBatch() is performed, reset the > statement's list of batch commands to empty. The JDBC spec isn't > 100% clear about this. This behaviour is only documented in the > Java tutorial > (http://java.sun.com/docs/books/tutorial/jdbc/jdbc2dot0/batchupdates.html). > Note that the Oracle JDBC driver also resets the statement's > list in executeBatch(), and this seems the most reasonable > interpretation. > > 5) A new test case is added to the JDBC test suite which tests > various aspects of batch processing. See the new file > BatchExecuteTest.java. > > Regards, > Ren? Pijlman [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [JDBC] JDBC Statement.executeBatch patch
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. > Attached is a patch for current CVS, consisting of a cvs diff -c > for the changed files and a few new files: > - test/jdbc2/BatchExecuteTest.java > - util/MessageTranslator.java > - jdbc2/PBatchUpdateException.java > > As an aside, is this the best way to submit a patch consisting > of both changed and new files? Or is there a smarter cvs command > which gets them all in one patch file? > > This patch fixes batch processing in the JDBC driver to be > JDBC-2 compliant. Specifically, the changes introduced by this > patch are: > > 1) Statement.executeBatch() no longer commits or rolls back a > transaction, as this is not prescribed by the JDBC spec. Its up > to the application to disable autocommit and to commit or > rollback the transaction. Where JDBC talks about "executing the > statements as a unit", it means executing the statements in one > round trip to the backend for better performance, it does not > mean executing the statements in a transaction. > > 2) Statement.executeBatch() now throws a BatchUpdateException() > as required by the JDBC spec. The significance of this is that > the receiver of the exception gets the updateCounts of the > commands that succeeded before the error occurred. In order for > the messages to be translatable, java.sql.BatchUpdateException > is extended by org.postgresql.jdbc2.PBatchUpdateException() and > the localization code is factored out from > org.postgresql.util.PSQLException to a separate singleton class > org.postgresql.util.MessageTranslator. > > 3) When there is no batch or there are 0 statements in the batch > when Statement.executeBatch() is called, do not throw an > SQLException, but silently do nothing and return an update count > array of length 0. The JDBC spec says "Throws an SQLException if > the driver does not support batch statements", which is clearly > not the case. See testExecuteEmptyBatch() in > BatchExecuteTest.java for an example. The message > postgresql.stat.batch.empty is removed from the language > specific properties files. > > 4) When Statement.executeBatch() is performed, reset the > statement's list of batch commands to empty. The JDBC spec isn't > 100% clear about this. This behaviour is only documented in the > Java tutorial > (http://java.sun.com/docs/books/tutorial/jdbc/jdbc2dot0/batchupdates.html). > Note that the Oracle JDBC driver also resets the statement's > list in executeBatch(), and this seems the most reasonable > interpretation. > > 5) A new test case is added to the JDBC test suite which tests > various aspects of batch processing. See the new file > BatchExecuteTest.java. > > Regards, > Ren? Pijlman [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html