Derby
  1. Derby
  2. DERBY-942

Add JDBC4 Ease of Development Support

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.2.1.6
    • Component/s: JDBC
    • Labels:
      None
    • Issue & fix info:
      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().

      1. derby-942_2.diff
        17 kB
        Anurag Shekhar
      2. derby-942.diff
        16 kB
        Anurag Shekhar
      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
        Rick Hillegas
      8. TestQueryObject.diff
        0.5 kB
        Rick Hillegas

        Activity

        Hide
        Rick 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.

        Show
        Rick 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.
        Hide
        Anurag Shekhar 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)

        Show
        Anurag Shekhar 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)
        Hide
        Anurag Shekhar 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.

        Show
        Anurag Shekhar 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.
        Hide
        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.

        Show
        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.
        Hide
        Rick 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

        Show
        Rick 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
        Hide
        Anurag Shekhar 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

        Show
        Anurag Shekhar 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
        Hide
        Rick 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

        Show
        Rick 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
        Hide
        Anurag Shekhar 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

        Show
        Anurag Shekhar 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
        Hide
        Rick 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!

        Show
        Rick 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!
        Hide
        Anurag Shekhar 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

        Show
        Anurag Shekhar 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
        Hide
        Anurag Shekhar 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

        Show
        Anurag Shekhar 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
        Hide
        Rick 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.

        Show
        Rick 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.
        Hide
        Anurag Shekhar added a comment -

        comitted in 386861

        Show
        Anurag Shekhar added a comment - comitted in 386861
        Hide
        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.

        Show
        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.
        Hide
        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

        Show
        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
        Hide
        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.

        Show
        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.
        Hide
        Rick Hillegas added a comment -

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

        Show
        Rick Hillegas added a comment - Commited derby-942-enable-connectionTest.diff at subversion revision 410591.
        Hide
        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.

        Show
        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.
        Hide
        Rick Hillegas added a comment -

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

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

          People

          • Assignee:
            Anurag Shekhar
            Reporter:
            Rick Hillegas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development