This is the net result of how the AbstractMMQueryTestCase would end up, because these are directly dependent on using the DriverManager:

static {
new TeiidDriver();
}


    private Stack<com.metamatrix.jdbc.api.Connection> contexts = new Stack<Connection>();

    

    public void pushConnection() {
    this.contexts.push(this.internalConnection);
    this.internalConnection = null;
    }

    

    public void popConnection() {
    this.internalConnection = this.contexts.pop();
    }

    

     public com.metamatrix.jdbc.api.Connection getConnection(String vdb, String propsFile){
        return getConnection(vdb, propsFile, "");  //$NON-NLS-1$
    }

    

    public com.metamatrix.jdbc.api.Connection getConnection(String vdb, String propsFile, String addtionalStuff){
    closeResultSet();
    closeStatement();
    closeConnection();
        try {
this.internalConnection = createConnection(vdb, propsFile, addtionalStuff);
} catch (SQLException e) {
throw new RuntimeException(e);
} 
        return this.internalConnection;
    }

    

    public static com.metamatrix.jdbc.api.Connection createConnection(String vdb, String propsFile, String addtionalStuff) throws SQLException {
        String url = "jdbc:metamatrix:"+vdb+"@" + propsFile+addtionalStuff; //$NON-NLS-1$ //$NON-NLS-2$
        return (com.metamatrix.jdbc.api.Connection)DriverManager.getConnection(url); 
    }    

        

      

    protected void helpTest(String query, String[] expected, String vdb, String props, String urlProperties) {
        getConnection(vdb, props, urlProperties);
        executeAndAssertResults(query, expected);
        closeConnection();
    }


With these changes, tt would enable the extender to control how the connection is created (i.e., from the MMDataSource).

Van


On Aug 27, 2009, at 10:23 AM, Ramesh Reddy wrote:

Van,

This class is utility class, in most situations it is extended by a
another class to write the test.

If you are looking to to provide abstractions for connections you can
certainly/override the "getConnection" calls or add others. You can
refactor to suit the needs, I just wondering if that requires pushing
the functionality to a base class (as this is already functionally a
abstract class)?

Thanks

Ramesh..

On Thu, 2009-08-27 at 09:59 -0500, Van Halbert wrote:
I would like to refactor AbstractMMQueryTestCase by pushing its core  
logic further down (new base class) for executing queries, comparing  
results, and common actions on the connection, etc. so that it can  
reused (extended) for any manner of tests that, in the end, use a  
Connection.    Also, this core logic is basic to jdbc testing and  
therefore would like to reuse this in the, soon to becoming,  
integration test project for testing transactions and running the ctc  
tests.     There was already a similar class, from whence it came  
from, in the JBEDSP integration test project.   So I would to  
consolidate this logic.

Any comments, complaints, suggestions, please speak up.    Otherwise I  
will commence with refactoring tomorrow.


Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert@redhat.com




_______________________________________________
teiid-dev mailing list
teiid-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev


Van Halbert
Principal Software Eng.
Red Hat, Inc.
------