Hey Andras, you're welcome. I'd suggest using Derby in file-mode as with the JDO integration tests. Its advantage is that you can use Maven to run your tests, you can simply clean the database and use the maven-sql-plugin to create your schema. The downside is that you have to set the working directory in Eclipse manually to the target folder (see my explanation in [2]).
In my opinion separating database configuration, schema creation and test data from test code is within the meaning of separation of concerns and way easier to handle. Imagine you want to write testcases for multiple databases (let's say Derby, MySQL or Oracle). Hard coded initialization of your database e.g. using a proprietary SQL dialect is more likely to kill test compliance with other databases. If you have any further questions, go ahead! Best, Lukas Am 28.03.2010 um 15:38 schrieb Andras Hatvani: > Lukas, > > thanks again for the rapid response. The issue was indeed, that the schema > wasn't created - the usage of the maven sql plugin isn't suited for this > purpose. Thus the schema creation has to be done programmatically, in this > case the test setup methods annotated with @Before or @BeforeClass. But as it > reduces execution time by order(s) of magnitude it can be worth using it, so > I'm still looking for an improvement regarding schema creation. > In the tests we use both, XML and programmatic configuration, but thanks for > the hint. > > Cheers, > Andras > > > On 2010 Mar 27, at 20:46, Lukas Lang wrote: > >> Hey Andras, >> >> I'm glad you asked. Derby indeed is supported by Castor as stated in the >> documentation [1]. I'm also very optimistic that additional parameter added >> to the JDBC connection URL will be handled correctly. Just to make that >> clear: Even when using in-memory embedded databases, you have to create and >> execute the schema by yourself. >> >> I'd guess that you're facing either a problem with working paths in your IDE >> or a problem with Maven? May I ask you to have a look at a conversation >> between me and the students from the last semester [2]? They had similar >> problems with setting the working directory in Eclipse properly. >> >> Furthermore, I think it is more convenient to use a XML file for >> configuration [3], but of course it is your decision. >> I hope that you can resolve your issues. Keep us informed! >> >> Regards, >> Lukas >> >> [1] http://castor.org/jdo-introduction.html >> [2] Castor-Dev: Problems setting up test framework, >> http://markmail.org/message/q3tfwvyeefqiawam >> [3] JDO Extensions: Integration tests, Derby config example, >> https://svn.codehaus.org/castor/castor/trunk/jdo-extensions-it/src/test/resources/org/castor/cpa/functional/single/jdo-conf.xml >> >> Am 27.03.2010 um 18:51 schrieb Andras Hatvani: >> >>> Hi, >>> >>> Derby supports in-memory databases since 10.5.1.1 and in the latest release >>> 10.5.3.0 this mode should be pretty stable, so I tried to use it with >>> Castor. >>> In order to let Derby know that it doesn't have to create files the >>> sub-protocol string 'memory:' has to be inserted into the connection >>> string, e.g. "jdbc:derby:memory:test;create=true". >>> >>> But in this case I get the following exception: >>> org.exolab.castor.jdo.PersistenceException: Nested error: >>> java.sql.SQLSyntaxErrorException: Schema 'TEST' does not exist >>> >>> When omitting the connection parameter i.e. only providing >>> "jdbc:derby:memory:test;" the following error will be raised: >>> org.exolab.castor.jdo.ConnectionFailedException: Nested error: >>> java.sql.SQLException: Database 'memory:test' not found. >>> >>> Code: >>> JDOManager.loadConfiguration(JDOConfFactory.createJdoConf( >>> JDOConfFactory.createDatabase("test", "derby", >>> JDOConfFactory.createDriver( >>> "org.apache.derby.jdbc.EmbeddedDriver", >>> "jdbc:derby:memory:test;", "test", "test"), >>> "mapping.xml"), JDOConfFactory >>> .createLocalTransactionDemarcation()), >>> this.getClass().getResource(".").toString()); >>> db = JDOManager.createInstance("test").getDatabase(); >>> >>> Does anyone have an explanation and ideally also a workaround for this >>> issue? >>> >>> Thanks, >>> Andras >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
