Lukas, I agree with you regarding the separation of concerns, that's why I want to find a solution, where the in-memory db can be used the same way as the file-based. Performance is very important to me, whether during a build or in production: I need instant or at least very fast feedback. :)
Cheers, Andras On 2010 Mar 28, at 15:54, Lukas Lang wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
