Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-942

Add JDBC4 Ease of Development Support

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 10.2.1.6
    • JDBC
    • None
    • Patch Available

    Description

      As described in the JDBC 4 spec, sections 20.1, 20.2, and 3.1.

      The Ease of Development extensions provide a way to create tabular DataSets from queries and tuple signatures. The jdk ships with a factory for creating these DataSets, which is a class which implements the QueryObjectGenerator interface. A database can write its own custom QueryObjectGenerator, or just ship with the default, jdk-shipped version. For this task, we will simply wire the default jdk-shipped factory into the appropriate methods: Connection.createQueryObject() and DataSource.createQueryObject().

      Attachments

        1. derby-942_2.diff
          17 kB
          Anurag Aggarwal
        2. derby-942.diff
          16 kB
          Anurag Aggarwal
        3. derby-942-connectiontest-rewrite.diff
          11 kB
          Kristian Waagan
        4. derby-942-connectiontest-rewrite.stat
          0.3 kB
          Kristian Waagan
        5. derby-942-enable-connectionTest.diff
          0.6 kB
          Kristian Waagan
        6. derby-942-enable-connectionTest.stat
          0.2 kB
          Kristian Waagan
        7. TestDbMetaData.diff
          1 kB
          Richard N. Hillegas
        8. TestQueryObject.diff
          0.5 kB
          Richard N. Hillegas

        Activity

          Here are sections 20.1 and 20.2 of the JDBC 4 spec:

          179
          20.1 Overview
          The JDBC Ease of Development features are intended to:
          ? Make it easier to execute SQL queries which return a single result set; execute
          SQL Data Manipulation Language (DML) statements that return a row count or
          that return nothing.
          ? This reduces the amount of code required to execute queries that normally
          would be executed using the Statement.executeQuery and
          Statement.executeUpdate methods.
          ? Simplify the developer experience for users who want to access, navigate and
          modify their data as rows and columns.
          ? Provide a means for more strongly typed data.
          ? Process the returned data in a connected or disconnected environment.
          ? Leverage the new features added to J2SE 5.0 such as generics and annotations.
          The JDBC Ease of Development features are not intended to:
          ? Be used as an Object-Relational Mapping (ORM) Technology. Developers who
          need the features found in an ORM Technology should consider using the Java
          Persistence API.
          ? Address more complex JDBC application needs such as processing multiple result
          sets.
          180 JDBC 4.0 Specification ? October 2005
          20.1.1 JDBC Annotations
          JDBC Annotations assist developer by reducing the amount of code that must be
          written when using the JDBC APIs. The annotations will be used in combination
          with Query interfaces and DataSet objects to simplify the access and processing of
          data that is returned as a single SQL result set.
          TABLE 20-1 lists the annotations provided in JDBC 4.0.
          20.1.2 Query Interface
          A Query interface defines a set of methods that are decorated with JDBC
          annotations. These annotations describe the SQL queries and SQL update statements
          to be invoked by a given method. A Query interface must be a subinterface of the
          BaseQuery interface. The interface must also specify how the data returned for a
          SQL query should be bound to a DataSet.
          TABLE 20-1 JDBC Annotations
          Annotation Description
          AutoGeneratedKeys Defines the fields within a DataSet
          representing the columns that are to be
          returned for auto-generated keys
          ResultColumn Maps a field within a DataSet to a specific
          column in a SQL ResultSet
          Select Associates a SQL Select statement with a
          method in a Query Interface
          Update Associates a SQL statement that may return
          an update count, with a method in a Query
          Interface
          Chapter 20 Ease of Development 181
          20.1.3 BaseQuery Interface
          The BaseQuery interface must be the superinterface for all Query interfaces. This
          interface defines methods for closing a concrete implementation of a Query interface
          and for determining if an instance of a Query object has been closed.
          20.1.4 DataSet interface
          The DataSet interface is a subinterface of java.util.List and provides a type
          safe view of the data returned from the execution of a SQL query. A DataSet
          interface is a parameterized type. The parameter type is a data class describing the
          columns for the rows that are returned from a method on a Query interface
          decorated by the Select annotation.
          A DataSet may operate in a connected or disconnected mode. When used in a
          connected mode, the DataSet is normally implemented as a ResultSet. A
          disconnected DataSet is normally implemented as a CachedRowSet.
          A DataSet object allows for the iteration through the rows that were returned using
          the java.util.Iterator API. A DataSet object allows user to iterate through
          the rows that were returned using the java.util.Iterator API.
          20.1.5 User-Defined Class
          A user-defined class is used to represent the type parameter for a DataSet. The
          class defines the fields that represent the columns returned from an underlying data
          store. The user-defined class may be specified in two ways: as a structure or as a
          JavaBeansTM component. The user-defined class must be created with an access
          modifier of public.
          Note - Throughout the rest of this chapter, this "user-defined class" will be referred
          to as data class.
          When the data class is used as a simple structure, it consists of public fields whose
          names match the columns in the data returned from a data source.
          public class Person {
          public String firstName;
          public String lastName;
          }
          CODE EXAMPLE 20-1 data class as a structure
          182 JDBC 4.0 Specification ? October 2005
          The data class can also be represented as a JavaBeansTM component, providing setters
          and getters, that match the column names in the returned data to access the fields.
          public class Person {
          private String firstName;
          private String lastName;
          public String getFirstName()

          { return firstName;}

          public String getLastName()

          { return lastName;}

          public void setFirstName(String fName)

          { firstName= fName;}

          public void setLastName(String lName)

          { lastName=lName;}

          }
          CODE EXAMPLE 20-2 data class as a JavaBean
          20.1.6 QueryObjectGenerator Interface
          The QueryObjectGenerator interface may be implemented by JDBC drivers. A
          QueryObjectGenerator is used to process JDBC annotations and to provide the
          mapping between DataSet objects and the resulting data returned by a method
          decorated with a Select annotation. The interface also contains the method
          createQueryObject that returns an instance of a Query interface.
          The method DatabaseMetaData.providesQueryObjectGenerator may be
          used to determine whether a JDBC driver provides a QueryObjectGenerator
          implementation.
          An implementation of QueryObjectGenerator is provided by Java SE 6.
          20.2 Creating an instance of a Query interface
          This section describes how to create a concrete implementation of a Query interface.
          The database table that will be used in the example was created by the following
          DDL:
          create table mammal(firstName varchar(20), lastName varchar(20), int
          age, int weight, description varchar(50), longDescription
          varchar(254), int key1, int key2);
          Chapter 20 Ease of Development 183
          CODE EXAMPLE 20-3 DDL used to create the mammal table
          20.2.1 Creating a Query Interface
          The following section will provide an example of creating a Query interface.
          Prior to creating a Query interface, developers should create any needed data classes
          that will be supplied as a type parameter for a DataSet. Please refer to the
          DataSet section for additional details.
          public class Mammal {
          public String firstName;
          public String lastName;
          public int age;
          public int weight;
          public String description;
          }
          CODE EXAMPLE 20-4 Mammal data class
          The methods of the Query interface are decorated with Select and Update
          annotations. Methods decorated by Select annotations will return instances of
          DataSet<T>.
          interface MyQueries extends BaseQuery {
          @Select(sql="SELECT lastName, description FROM mammal")
          DataSet<Mammal> getAllMammals();
          @Update(sql="delete from mammals")
          int deleteAllMammals();
          }
          CODE EXAMPLE 20-5 A sample Query interface
          20.2.2 Concrete Query Interface implementation
          A concrete implementation of a Query interface can be created by invoking either
          the Connection.createQueryObject or DataSource.createQueryObject
          method passing a Query interface as its parameter.
          Connection con = DriverManager.getConnection(url, props);
          MyQueries myQueries = con.createQueryObject(MyQueries.class);
          CODE EXAMPLE 20-6 Creating an instance of a SQL Interface
          20.2.2.1 Connection.createQueryObject and
          DataSource.createQueryObject methods
          JDBC drivers must implement the createQueryObject method on the
          Connection and DataSource interface. If the JDBC driver does not provide its
          own implementation of a QueryObjectGenerator, it must invoke the default
          QueryObjectGenerator implementation provided by Java SE 6.
          When DataSource.createQueryObject is used for creating a Query object
          instance, a Connection will be obtained from the DataSource and used when
          executing a method on the Query interface. The QueryObjectGenerator
          implementation will be responsible for closing the Connection.
          If Connection.createQueryObject is used for creating a Query object instance,
          the application is responsible for closing the connection..
          20.2.2.2 Invoking Query Interface Methods
          Once you have created an implementation of the Query interface, you may invoke
          any of the methods that are defined by the interface.
          DataSet<Mammal> mammalRows = myQueries.getAllMammals();
          CODE EXAMPLE 20-7 invoking a method on the Query interface
          20.2.2.3 Closing a Query Object
          An application must explictly close a Query object by calling the close method.
          The close method will close any connected DataSets created from the Query
          object, thereby releasing any external resources and making it available for garbage
          collection.

          rhillegas Richard N. Hillegas added a comment - Here are sections 20.1 and 20.2 of the JDBC 4 spec: 179 20.1 Overview The JDBC Ease of Development features are intended to: ? Make it easier to execute SQL queries which return a single result set; execute SQL Data Manipulation Language (DML) statements that return a row count or that return nothing. ? This reduces the amount of code required to execute queries that normally would be executed using the Statement.executeQuery and Statement.executeUpdate methods. ? Simplify the developer experience for users who want to access, navigate and modify their data as rows and columns. ? Provide a means for more strongly typed data. ? Process the returned data in a connected or disconnected environment. ? Leverage the new features added to J2SE 5.0 such as generics and annotations. The JDBC Ease of Development features are not intended to: ? Be used as an Object-Relational Mapping (ORM) Technology. Developers who need the features found in an ORM Technology should consider using the Java Persistence API. ? Address more complex JDBC application needs such as processing multiple result sets. 180 JDBC 4.0 Specification ? October 2005 20.1.1 JDBC Annotations JDBC Annotations assist developer by reducing the amount of code that must be written when using the JDBC APIs. The annotations will be used in combination with Query interfaces and DataSet objects to simplify the access and processing of data that is returned as a single SQL result set. TABLE 20-1 lists the annotations provided in JDBC 4.0. 20.1.2 Query Interface A Query interface defines a set of methods that are decorated with JDBC annotations. These annotations describe the SQL queries and SQL update statements to be invoked by a given method. A Query interface must be a subinterface of the BaseQuery interface. The interface must also specify how the data returned for a SQL query should be bound to a DataSet. TABLE 20-1 JDBC Annotations Annotation Description AutoGeneratedKeys Defines the fields within a DataSet representing the columns that are to be returned for auto-generated keys ResultColumn Maps a field within a DataSet to a specific column in a SQL ResultSet Select Associates a SQL Select statement with a method in a Query Interface Update Associates a SQL statement that may return an update count, with a method in a Query Interface Chapter 20 Ease of Development 181 20.1.3 BaseQuery Interface The BaseQuery interface must be the superinterface for all Query interfaces. This interface defines methods for closing a concrete implementation of a Query interface and for determining if an instance of a Query object has been closed. 20.1.4 DataSet interface The DataSet interface is a subinterface of java.util.List and provides a type safe view of the data returned from the execution of a SQL query. A DataSet interface is a parameterized type. The parameter type is a data class describing the columns for the rows that are returned from a method on a Query interface decorated by the Select annotation. A DataSet may operate in a connected or disconnected mode. When used in a connected mode, the DataSet is normally implemented as a ResultSet. A disconnected DataSet is normally implemented as a CachedRowSet. A DataSet object allows for the iteration through the rows that were returned using the java.util.Iterator API. A DataSet object allows user to iterate through the rows that were returned using the java.util.Iterator API. 20.1.5 User-Defined Class A user-defined class is used to represent the type parameter for a DataSet. The class defines the fields that represent the columns returned from an underlying data store. The user-defined class may be specified in two ways: as a structure or as a JavaBeansTM component. The user-defined class must be created with an access modifier of public. Note - Throughout the rest of this chapter, this "user-defined class" will be referred to as data class. When the data class is used as a simple structure, it consists of public fields whose names match the columns in the data returned from a data source. public class Person { public String firstName; public String lastName; } CODE EXAMPLE 20-1 data class as a structure 182 JDBC 4.0 Specification ? October 2005 The data class can also be represented as a JavaBeansTM component, providing setters and getters, that match the column names in the returned data to access the fields. public class Person { private String firstName; private String lastName; public String getFirstName() { return firstName;} public String getLastName() { return lastName;} public void setFirstName(String fName) { firstName= fName;} public void setLastName(String lName) { lastName=lName;} } CODE EXAMPLE 20-2 data class as a JavaBean 20.1.6 QueryObjectGenerator Interface The QueryObjectGenerator interface may be implemented by JDBC drivers. A QueryObjectGenerator is used to process JDBC annotations and to provide the mapping between DataSet objects and the resulting data returned by a method decorated with a Select annotation. The interface also contains the method createQueryObject that returns an instance of a Query interface. The method DatabaseMetaData.providesQueryObjectGenerator may be used to determine whether a JDBC driver provides a QueryObjectGenerator implementation. An implementation of QueryObjectGenerator is provided by Java SE 6. 20.2 Creating an instance of a Query interface This section describes how to create a concrete implementation of a Query interface. The database table that will be used in the example was created by the following DDL: create table mammal(firstName varchar(20), lastName varchar(20), int age, int weight, description varchar(50), longDescription varchar(254), int key1, int key2); Chapter 20 Ease of Development 183 CODE EXAMPLE 20-3 DDL used to create the mammal table 20.2.1 Creating a Query Interface The following section will provide an example of creating a Query interface. Prior to creating a Query interface, developers should create any needed data classes that will be supplied as a type parameter for a DataSet. Please refer to the DataSet section for additional details. public class Mammal { public String firstName; public String lastName; public int age; public int weight; public String description; } CODE EXAMPLE 20-4 Mammal data class The methods of the Query interface are decorated with Select and Update annotations. Methods decorated by Select annotations will return instances of DataSet<T>. interface MyQueries extends BaseQuery { @Select(sql="SELECT lastName, description FROM mammal") DataSet<Mammal> getAllMammals(); @Update(sql="delete from mammals") int deleteAllMammals(); } CODE EXAMPLE 20-5 A sample Query interface 20.2.2 Concrete Query Interface implementation A concrete implementation of a Query interface can be created by invoking either the Connection.createQueryObject or DataSource.createQueryObject method passing a Query interface as its parameter. Connection con = DriverManager.getConnection(url, props); MyQueries myQueries = con.createQueryObject(MyQueries.class); CODE EXAMPLE 20-6 Creating an instance of a SQL Interface 20.2.2.1 Connection.createQueryObject and DataSource.createQueryObject methods JDBC drivers must implement the createQueryObject method on the Connection and DataSource interface. If the JDBC driver does not provide its own implementation of a QueryObjectGenerator, it must invoke the default QueryObjectGenerator implementation provided by Java SE 6. When DataSource.createQueryObject is used for creating a Query object instance, a Connection will be obtained from the DataSource and used when executing a method on the Query interface. The QueryObjectGenerator implementation will be responsible for closing the Connection. If Connection.createQueryObject is used for creating a Query object instance, the application is responsible for closing the connection.. 20.2.2.2 Invoking Query Interface Methods Once you have created an implementation of the Query interface, you may invoke any of the methods that are defined by the interface. DataSet<Mammal> mammalRows = myQueries.getAllMammals(); CODE EXAMPLE 20-7 invoking a method on the Query interface 20.2.2.3 Closing a Query Object An application must explictly close a Query object by calling the close method. The close method will close any connected DataSets created from the Query object, thereby releasing any external resources and making it available for garbage collection.

          This patch is meant only for review. Because of bug in current version of jdk1.6 (mustang) ResultSet.getType after closing connection resulting in exception while network client. Embedded driver uses a light weight check for all the methods which doesn't checks for connection in this call.

          I have set the noSecurityManager to true for testing this feature.
          Default implementation of QueryObjectGenerator uses reflection check the DataObject before invokeing setters. Reflection being privileged operation fails when called with default security manager.

          Description of patch
          java/engine/org/apache/derby/jdbc/EmbeddedDataSource40.java
          java/client/org/apache/derby/jdbc/ClientDataSource40.java
          added code to call DefaultQueryGenerator
          added code to return null for getQueryObjectGenerator to indicate this jdbc doesn't have QueryObjectGenerator and relies on the default implementation.

          java/engine/org/apache/derby/impl/jdbc/EmbedConnection40.java
          java/client/org/apache/derby/client/net/NetConnection40.java
          added code to call DefaultQueryGenerator

          build.xml
          added additinla target to uncomment jdbc4 class name listed in tools/jar/extraDBMSclasses.properties if the build is made with jdbc4 support

          tools/jar/extraDBMSclasses.properties
          added entry for EmbeddedDataSource40 so that it it gets added to derby.jar (right now its not getting added to this)

          anurag Anurag Aggarwal added a comment - This patch is meant only for review. Because of bug in current version of jdk1.6 (mustang) ResultSet.getType after closing connection resulting in exception while network client. Embedded driver uses a light weight check for all the methods which doesn't checks for connection in this call. I have set the noSecurityManager to true for testing this feature. Default implementation of QueryObjectGenerator uses reflection check the DataObject before invokeing setters. Reflection being privileged operation fails when called with default security manager. Description of patch java/engine/org/apache/derby/jdbc/EmbeddedDataSource40.java java/client/org/apache/derby/jdbc/ClientDataSource40.java added code to call DefaultQueryGenerator added code to return null for getQueryObjectGenerator to indicate this jdbc doesn't have QueryObjectGenerator and relies on the default implementation. java/engine/org/apache/derby/impl/jdbc/EmbedConnection40.java java/client/org/apache/derby/client/net/NetConnection40.java added code to call DefaultQueryGenerator build.xml added additinla target to uncomment jdbc4 class name listed in tools/jar/extraDBMSclasses.properties if the build is made with jdbc4 support tools/jar/extraDBMSclasses.properties added entry for EmbeddedDataSource40 so that it it gets added to derby.jar (right now its not getting added to this)

          I haven't used junit for the test cases because right now the DerbyJunit doesn't provides any method to return DataSource and the test case needs to test DataSource method.

          anurag Anurag Aggarwal added a comment - I haven't used junit for the test cases because right now the DerbyJunit doesn't provides any method to return DataSource and the test case needs to test DataSource method.

          I mentioned this in connection to DERBY-993. There is code already in org.apache.derbyTesting.functionTests.util.TestUtil to obtain a connection using a DataSource. This code can probably be reused with JUnit tests without much effort.

          fuzzylogic Samuel Andrew McIntyre added a comment - I mentioned this in connection to DERBY-993 . There is code already in org.apache.derbyTesting.functionTests.util.TestUtil to obtain a connection using a DataSource. This code can probably be reused with JUnit tests without much effort.

          Hi Anurag,

          Thanks for the preliminary peek at this patch. Looks good. I like the way you handled the optional inclusion of the JDBC4-specific classes in the jar file. I recommend adding class and method comments to the test classes so that reviewers will know what these tests are supposed to stress. Thanks for the explanation of why you disabled the SecurityManager and for commenting the property file accordingly. When we do commit this patch, let's leave the JIRA open to remind us to re-enable the SecurityManager after mustang fixes its bug.

          Cheers-Rick

          rhillegas Richard N. Hillegas added a comment - Hi Anurag, Thanks for the preliminary peek at this patch. Looks good. I like the way you handled the optional inclusion of the JDBC4-specific classes in the jar file. I recommend adding class and method comments to the test classes so that reviewers will know what these tests are supposed to stress. Thanks for the explanation of why you disabled the SecurityManager and for commenting the property file accordingly. When we do commit this patch, let's leave the JIRA open to remind us to re-enable the SecurityManager after mustang fixes its bug. Cheers-Rick

          added coments in test classes

          build 74 of jdk1.6 includes the bug i mentioned in my privious description
          jdbc4 test suite runs fine with these changes

          anurag Anurag Aggarwal added a comment - added coments in test classes build 74 of jdk1.6 includes the bug i mentioned in my privious description jdbc4 test suite runs fine with these changes

          Unfortunately, when I run the jdbc4 suite I see diffs in the following tests. I have attached the diff files.

          jdbc4/TestDbMetaData.java
          jdbc4/TestQueryObject.java

          rhillegas Richard N. Hillegas added a comment - Unfortunately, when I run the jdbc4 suite I see diffs in the following tests. I have attached the diff files. jdbc4/TestDbMetaData.java jdbc4/TestQueryObject.java

          jdbc4/TestDbMetaData ois failing because message has changed after 1061 fix. This will change again after 1059 is commited. I will update the out file then.
          The error in jdbc4/TestQueryObject.java is due to a bug in jdk which was fixed in jdk 1.6 build 74. It works fine with recent jdk builds

          anurag Anurag Aggarwal added a comment - jdbc4/TestDbMetaData ois failing because message has changed after 1061 fix. This will change again after 1059 is commited. I will update the out file then. The error in jdbc4/TestQueryObject.java is due to a bug in jdk which was fixed in jdk 1.6 build 74. It works fine with recent jdk builds

          Hi Anurag,

          Thanks for the explanation. I have upgraded to mustang build 76 and that indeed fixed the TestQueryObject problem.

          Since the other test is broken, it sounds like this patch is not ready to commit. When you are ready, please say in your submission comment that the patch is ready for committing and not just reviewing. Thanks!

          rhillegas Richard N. Hillegas added a comment - Hi Anurag, Thanks for the explanation. I have upgraded to mustang build 76 and that indeed fixed the TestQueryObject problem. Since the other test is broken, it sounds like this patch is not ready to commit. When you are ready, please say in your submission comment that the patch is ready for committing and not just reviewing. Thanks!

          Hi Rick
          jdbc4/TestDbMetaData.java is not part of this patch actulally its already in and failing in nightly runs (http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/Limited/testSummary-386413.html)
          I will upload out file for that as part of some other jira issue

          anurag Anurag Aggarwal added a comment - Hi Rick jdbc4/TestDbMetaData.java is not part of this patch actulally its already in and failing in nightly runs ( http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/Limited/testSummary-386413.html ) I will upload out file for that as part of some other jira issue

          Hi Rick
          jdbc4/TestDbMetaData.java is not part of this patch actulally its already in and failing in nightly runs (http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/Limited/testSummary-386413.html)
          I will upload out file for that as part of some other jira issue
          anurag

          anurag Anurag Aggarwal added a comment - Hi Rick jdbc4/TestDbMetaData.java is not part of this patch actulally its already in and failing in nightly runs ( http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/Limited/testSummary-386413.html ) I will upload out file for that as part of some other jira issue anurag

          Thanks for the explanation. It's sad that that other test is broken but I can see that your patch has nothing to do with it.

          I ran derbyall: wisconsin fails as it does in the tinderbox tests. I saw the following failure in SqlExceptionTest (I also see this failure in a clean client just torn off the subversion repository):

          0 add
          > java.lang.NoSuchMethodError: main
          > Exception in thread "main"
          Test Failed.

          I have committed this patch as subversion revision 386861.

          rhillegas Richard N. Hillegas added a comment - Thanks for the explanation. It's sad that that other test is broken but I can see that your patch has nothing to do with it. I ran derbyall: wisconsin fails as it does in the tinderbox tests. I saw the following failure in SqlExceptionTest (I also see this failure in a clean client just torn off the subversion repository): 0 add > java.lang.NoSuchMethodError: main > Exception in thread "main" Test Failed. I have committed this patch as subversion revision 386861.

          comitted in 386861

          anurag Anurag Aggarwal added a comment - comitted in 386861

          I have attached the patch 'derby-942-enable-connectionTest.diff', which enables the jdbc4/ConnectionTest as part of the jdbc40 suite. The test no longer fails as the method createQueryObject has been fully implemented. I ran suite jdbc40 without any failures under both embedded and DerbyNetClient.

          When the patch is committed, it think this issue can be closed.

          kristwaa Kristian Waagan added a comment - I have attached the patch 'derby-942-enable-connectionTest.diff', which enables the jdbc4/ConnectionTest as part of the jdbc40 suite. The test no longer fails as the method createQueryObject has been fully implemented. I ran suite jdbc40 without any failures under both embedded and DerbyNetClient. When the patch is committed, it think this issue can be closed.
          narayanan V.Narayanan added a comment -

          The tests test the PooledConnection and XAConnections as well. They should actually be modified so that they can run in as part of the jdbcxa40 suite so that setting the derbyTesting.xa.single property will take care of testing for the XAConnection case as well and we need not do this explicitly in the test.

          thanx
          Narayanan

          narayanan V.Narayanan added a comment - The tests test the PooledConnection and XAConnections as well. They should actually be modified so that they can run in as part of the jdbcxa40 suite so that setting the derbyTesting.xa.single property will take care of testing for the XAConnection case as well and we need not do this explicitly in the test. thanx Narayanan

          What you describe can be done by deleting the two subclasses in ConnectionTest, clean up the suite() method, adjust the documentation and add ConnectionTest to the xa suite. I suppose we do not really need the pooled connection test, as the connection implementation class is the same as for xa.

          Unless someone wants to keep the test as it is (where regular, pooled and xa connections are all tested), I will add a Jira and rewrite the neccessary parts of the test class in a few days.

          kristwaa Kristian Waagan added a comment - What you describe can be done by deleting the two subclasses in ConnectionTest, clean up the suite() method, adjust the documentation and add ConnectionTest to the xa suite. I suppose we do not really need the pooled connection test, as the connection implementation class is the same as for xa. Unless someone wants to keep the test as it is (where regular, pooled and xa connections are all tested), I will add a Jira and rewrite the neccessary parts of the test class in a few days.

          Commited derby-942-enable-connectionTest.diff at subversion revision 410591.

          rhillegas Richard N. Hillegas added a comment - Commited derby-942-enable-connectionTest.diff at subversion revision 410591.

          'derby-942-connectiontest-rewrite.diff' rewrites ConnectionTest to only test a single connection implementation class. Which class is tested, depends on what 'BaseJDBCTestCase.getConnection()' returns.
          The test is also added to the 'jdbcxa40' suite, but I could not see this suite being run as part of any other suites (including derbyall).
          The parts that were removed from the test, can be tested by using the 'derbyTesting.xa.single' property instead. I assume this will be used when the jdbcxa40 suite is being run.

          Suite jdbc40 passed without failures. Derbyall has not been run for this JDBC4-only patch.

          Please commit.

          kristwaa Kristian Waagan added a comment - 'derby-942-connectiontest-rewrite.diff' rewrites ConnectionTest to only test a single connection implementation class. Which class is tested, depends on what 'BaseJDBCTestCase.getConnection()' returns. The test is also added to the 'jdbcxa40' suite, but I could not see this suite being run as part of any other suites (including derbyall). The parts that were removed from the test, can be tested by using the 'derbyTesting.xa.single' property instead. I assume this will be used when the jdbcxa40 suite is being run. Suite jdbc40 passed without failures. Derbyall has not been run for this JDBC4-only patch. Please commit.

          Committed derby-942-connectiontest-rewrite.diff at subversion revision 410945. JDBC4 tests ran cleanly.

          rhillegas Richard N. Hillegas added a comment - Committed derby-942-connectiontest-rewrite.diff at subversion revision 410945. JDBC4 tests ran cleanly.

          People

            anurag Anurag Aggarwal
            rhillegas Richard N. Hillegas
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: