-
1. Re: Clustering tests and hsqldb
timfox Nov 1, 2006 4:55 AM (in response to timfox)I have also updated the release checklist to make sure the clustering tests are run
-
2. Re: Clustering tests and hsqldb
starksm64 Nov 2, 2006 8:24 PM (in response to timfox)What about just switching to another embedded database such as derby or javadb?
-
3. Re: Clustering tests and hsqldb
ovidiu.feodorov Nov 2, 2006 11:04 PM (in response to timfox)Tim wrote:
For now though, could everyone ensure they run the clustering-tests target before committing after they run the normal test suite? Thanks
Why don't you add the clustering-tests target to "tests"?
Also, you can configure the default database on a test-by-test basis, by overriding the value of < property name="functional.tests.database" value="hsqldb" />. Override it when you call < antcall target="clustering-tests"/>Scott wrote:
What about just switching to another embedded database such as derby or javadb?
We can do that, but I have one question and one observation related to this.
The question is why JBoss AS doesn't use derby or javadb instead of hsqldb?
The observation is that the value of the database a certain tests runs in top of can be changed on a test-by-test basis, so by just having an MySQL instance in stand by and configuring the tests to run with "mysql" would be sufficient. We already need MySQL for stress tests, so this would be the simplest way to get address the problem. -
4. Re: Clustering tests and hsqldb
starksm64 Nov 3, 2006 1:56 AM (in response to timfox)"ovidiu.feodorov@jboss.com" wrote:
We can do that, but I have one question and one observation related to this.
The question is why JBoss AS doesn't use derby or javadb instead of hsqldb?
We most likely will since that is what we are certifying with. -
5. Re: Clustering tests and hsqldb
timfox Nov 3, 2006 4:15 AM (in response to timfox)We could certainly use a different embedded database than HSQL for those tests that only require an embedded database.
However some of the tests, e.g. some of the clustering tests require a shared database that can be seen by all nodes in the cluster.
My point was, basically we should make the default test database a shared database, e.g. mysql so we can run the entire test suite.
When the tests are run against an embedded database, e.g. javadb, hsql or whatever not all the tests can be run which is not ideal.
Eventually this will be solved by running all tests against the full database matrix (Ryan told me we are on the waiting list for this after hibernate and jbpm) but until then I wanted a stop-gap solution.