|
|
|
[
Permlink
| « Hide
]
Werner Guttmann - 14/Dec/04 06:49 AM
Bruce ?
Martin, I think by specifying a new category, this should do the trick. Once
you've done that, you'll be able to specify a separate JDO config file. Martin, just reading through this again, and it just occured to me that we ship
by definition the postgreSQL JDBC driver as part of the complete distribution JAR. What woukld you thin of converting your test case to use a postgreSQL instance with default port numnbers and database names ? I intend to commit attached test after some small changes into src/tests/jdo/test1785 directory without integration into CTF. The integartion of this test and also 3 others (test1214, test1781and test1865) into CTF need to take place later as we will need a bigger refactoring of CTF for this to be done first. The problem is that we can only handle one jdo-conf at CTF yet and all this tests requiere to change the configuration during the test.
+1. Let's get this committed in time for 0.9.7. The more tests the better.
Question 1: Can you think about any 'dirty' way of allowing configuration of the RDBMS when running these tests, other than manually editing jdo-conf.xml files ? Question 2: As we are adding more and more tests outside the CTF, I think we should add a test suite as well, and include all tests by definition. This way running these tests will be easier. to 1 above: The idea is to have a base configuration (the one we have yet), clone that one, change name and parameters (e.g. mapping) and use that one for the test.
to 2 above: I intend to continue my work on refactoring CTF and hope to be able to integrate the seperate tests until the release after 0.9.7. Until this time I wanted to leave the seperate tests. When trying to resolve this I was hit by 3 different things:
1) Current CTF do not allow to load differnt configurations. This can not be resolved without a bigger refactoring of the test framework therefore this need to be a standalone test for the moment. 2) There is another standanlone test at jdo.test1781 that tests to load a driver configuration with JDOConfFactory. I decided to add a new test to load datasource configuration with JDOConfFactoryto to this one. 3) The third thing appers to be the biggest one as the test always failed at setting the properties at datasource. The problem was that we used Castor XML to unmarshal the jdo-conf.xml file a second time to set the parameters at the datasource. Obviously we have a JdoConf instance as a in memory configuration but we don't have a jdo-conf.xml file when working with JDOConfFactory. The aproach to set properties at datasource could therefore never work with JDOConfFactory. I now directly use reflection to set the parameter on the datasource. The patch have been tested with mysql using DHCP datasource and sapdb. Still tests with oracle are missing but this will be done when preparing the next release and I don't expect to see any problems there. I'm missing any comment why this issue has been reopend. The only problems that could have caused this are:
1) no exception thrown at a paramater that could not be set Both of this issues has been resolved while working at While working at
cache-scheme=1 still the syntax with using the CACHE_SCHEME_DYNAMIC constant of the oracle driver is not possible but IMO not required. I'll therefore close this issue as duplicate. |