pgsql/src/interfaces/jdbc/org/postgresql jdbc2 ... - Mailing list pgsql-committers

CVSROOT:    /home/projects/pgsql/cvsroot
Module name:    pgsql
Changes by:    scrappy@hub.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