[
http://jira.jboss.com/jira/browse/JBAS-4152?page=comments#action_12375457 ]
Heiko W. Rupp commented on JBAS-4152:
-------------------------------------
Ok, I don't recall every detail aymore :-)
What I did was a <dbindex/> tag in the relationships (as well as for fields) as most
DBs don't automatically put indexes on fks (as oposed to what hsql did).
Now I put an index on one side of the relation and not on the 2nd one.
That 2nd one is now failing, as the test code detects an index, which should not be
there.
I *guess* that hsqldb is now putting in an index there that does not start with
"pk_idx" (those get filtered) which gets detected by the failing test, as it
does not expect it.
Is there a "preconfigured" jboss as with the new hsqldb and the test(suite)
soewhere available?
Upgrade to hsql 1.8.0.7 causes
org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2 to fail
-------------------------------------------------------------------------------------------------------------------
Key: JBAS-4152
URL:
http://jira.jboss.com/jira/browse/JBAS-4152
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: EJB2
Environment: BEA JRockit 1.5.0_08 on Red Hat Enterprise Linux AS release 4
(Nahant Update 4)
Reporter: Vivek Lakshmanan
Assigned To: Heiko W. Rupp
Fix For: JBossAS-4.2.2.GA
On upgrade of HSQLDB from 1.8.0.2 to 1.8.0.7 the following testcase seems to consistently
fail:
org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2
Error: FKey cmr2_id is indexed
The test reports say:
junit.framework.AssertionFailedError: Error: FKey cmr2_id is indexed
at
org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase.testCMRmn2(IdxAndUsersqlUnitTestCase.java:190)
at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133)
at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102)
at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at
org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at
org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
The sourcefile for the test says:
/*
* Look for indices on the m:n mapping table
* This is for hsql a strange case, at indices are put there
* anyway, but it has been told that other databases don't do
* it by themselves, so we check if the creation succeeds.
*/
Would like to get an experts opinion on it
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira