Skip site navigation (1) Skip section navigation (2)

pgsql/src/interfaces/jdbc/org/postgresql jdbc2 ...

From: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql/src/interfaces/jdbc/org/postgresql jdbc2 ...
Date: 2001-09-06 03:11:59
Message-ID: 200109060311.f863BxG46640@hub.org (view raw or flat)
Thread:
Lists: pgsql-committers
CVSROOT:	/home/projects/pgsql/cvsroot
Module name:	pgsql
Changes by:	scrappy(at)hub(dot)org	01/09/05 23:11:59

Modified files:
	src/interfaces/jdbc/org/postgresql/jdbc2: DatabaseMetaData.java 
	                                          Statement.java 
	src/interfaces/jdbc/org/postgresql/test: JDBC2Tests.java 
	src/interfaces/jdbc/org/postgresql/util: PSQLException.java 
Added files:
	src/interfaces/jdbc/org/postgresql/test/jdbc2: 
	                                               BatchExecuteTest.java 
	src/interfaces/jdbc/org/postgresql/util: MessageTranslator.java 

Log message:
	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


pgsql-committers by date

Next:From: Marc G. FournierDate: 2001-09-06 03:13:34
Subject: pgsql/src/interfaces/jdbc/org/postgresql Conne ...
Previous:From: Marc G. FournierDate: 2001-09-06 03:07:27
Subject: pgsql/src/interfaces/jdbc/org/postgresql error ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group