Use of DriverManager in tests

[Øystein Grøvlen <Oy...@sun.com>]

When developing a test for Derby-230, I was made aware of that we
should not use the DriverManager directly, but instead use
startJBMS().  However, I see some test (e.g.,
store/backupRestore1.java) that uses the DriverManager when shutting
down the database and when doing restore.  I am currently working on a
test for Derby-298 that needs to do the same.  Is it OK to do it this
way?   What restriction does it impose on which environment the test
can be run in? 

-- 
Øystein

Re: Use of DriverManager in tests

[Myrna van Lunteren <m....@gmail.com>]

On 6/2/05, Daniel John Debrunner <dj...@debrunners.com> wrote: 
> 
> Øystein Grøvlen wrote:
> 
> > When developing a test for Derby-230, I was made aware of that we
> > should not use the DriverManager directly, but instead use
> > startJBMS(). However, I see some test (e.g.,
> > store/backupRestore1.java) that uses the DriverManager when shutting
> > down the database and when doing restore. I am currently working on a
> > test for Derby-298 that needs to do the same. Is it OK to do it this
> > way? What restriction does it impose on which environment the test
> > can be run in?
> 
> J2ME does not suport DriverManager. This is because the JDBC JSR169
> subset only supports javax.sql.DataSource as the connection mechanism.
> 
> I currently have the test suite running under J2ME with about a 50% pass
> rate. Many of those failures are due to use of DriverManager, which I
> will look at fixing in one way or another.
> 
> So at the momeent I would request anyone to minimize use of
> DriverManager, but if it is needed then use it.
> 
> 
> Dan.
> 
> 
> Before, I mentioned that in RunTest, when running with -Duseprocess=false, 
a call is made to DriverManager:
 try 
{
java.sql.DriverManager.getConnection("jdbc:derby:;shutdown=true");
} 
catch (java.sql.SQLException e) 
{
// ignore the errors, they are expected.
}
I imagine other tests are doing something similar. Without DriverManager, 
this of course results in a ClassNotFoundDef error.
I spent some time, after Kathey's suggestion on another branch, to use 
...functionTests.util.TestUtil to shutdown the database, and I think this 
should work as a replacement for using
DriverManager.getConnection("jdbc:derby:<db>;shutdown=true").
In the case of RunTest, I'm wary of making big waves, so I am thinking of 
changing the above section to:
  try 
{
java.sql.DriverManager.getConnection("jdbc:derby:;shutdown=true");
} 
catch (java.sql.SQLException e) 
{
// ignore the errors, they are expected.
}
// maybe we're running with a DataSource in J2ME.
// then we get an ClassNotFoundDef error on DriverManager.getConnection
catch (Throwable th) 
{
Properties attrs = new Properties();
attrs.setProperty("shutdownDatabase", "shutdown");
try {
DataSource ds = TestUtil.getDataSource(attrs);
ds.getConnection();
} catch (Throwable ith) {
ith.printStackTrace();
}
}

Any reason why this would not work? Should we remove the DriverManager call 
altogether & replace with the DataSource call?
 Thx,
Myrna

Re: Use of DriverManager in tests

[Daniel John Debrunner <dj...@debrunners.com>]

Øystein Grøvlen wrote:

> When developing a test for Derby-230, I was made aware of that we
> should not use the DriverManager directly, but instead use
> startJBMS().  However, I see some test (e.g.,
> store/backupRestore1.java) that uses the DriverManager when shutting
> down the database and when doing restore.  I am currently working on a
> test for Derby-298 that needs to do the same.  Is it OK to do it this
> way?   What restriction does it impose on which environment the test
> can be run in? 

J2ME does not suport DriverManager. This is because the JDBC JSR169
subset only supports javax.sql.DataSource as the connection mechanism.

I currently have the test suite running under J2ME with about a 50% pass
rate. Many of those failures are due to use of DriverManager, which I
will look at fixing in one way or another.

So at the momeent I would request anyone to minimize use of
DriverManager, but if it is needed then use it.


Dan.