Hi, > I did a little digging on this and I'm not sure relying on JavaDB is such a > sure > bet. Its a verbatim copy of Derby 10.2 and while bundled in with the jvm, its > not in the classpath by default. Also, I have 2 Oracle 1.6 JVMs on my PC and > only 1 includes it. Also, while the documentation says it is in the "db" > directory, > on my installation its in the "javadb" directory. It would be tricky at best > to > reliably get this in the tester's classpath, I think. It would be safer I > think to just > include the jar.
Thanks for taking care! I just wanted to mention this, as I was browsing Oracles Webpage today (downloading 7u4) and this came into my mind (and I remembered that there was something like javadb, but I was not sure if it was part of official Java spec). So as its only verbatim bundled and uses the apache package name, its definitely not standard, it's just a goodie for JDK. And as it is not even in classpath, forget about it :-) > My thoughts were to eventually migrate the example to use derby instead of > hsqldb. Maybe I should either change my test to use hsqldb or change the > example to use derby. Then as Robert points out, its just a minor build > modification to use the jar from the example. In any case, the current Mock > datasource doesn't emulate a real JDBC driver very well and I found it was > extremely simple to use Derby in in-memory embedded mode (All you do is > issue "DriverManager#getConnection" with the correct string). There are no > config files, etc. I agree here. Emulating a JDBC driver as a Mock is almost undoable, as it would need to implement a lot of interfaces with complex API, including a SQL query parser. That's undoable with few lines of code. Important for JDBC testing is only that you have an in-process database (HSQLDB or as you mention Derby) that needs no disk space and runs completely in memory and needs no configuration. Setting up test cases is easy then, as you say. You just have to create a "Mock" database using some "CREATE TABLE" and "INSERT" statements and you can start testing. > I don't know if you want to call this a "unit" test or an "integration" test > (and > what are all those other Solr tests that use Jetty, etc?). In the end, I > just want > readable tests that are true to real life, which DIH lacks right now. I agree! Uwe > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Wednesday, May 02, 2012 2:16 PM > To: dev@lucene.apache.org > Subject: RE: Help: SOLR-3430 and Build changes > > I have not checked this, but if the JavaDB is in the JDK official JavaDocs > and is > therefore part of JDK6 spec? We have to check this, but *if* the package names > start with java.db or whatever it *has* to be also in alternate JDK impls. At > least OpenJDK also downloads derby while building. > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -----Original Message----- > > From: Robert Muir [mailto:rcm...@gmail.com] > > Sent: Wednesday, May 02, 2012 8:42 PM > > To: dev@lucene.apache.org > > Subject: Re: Help: SOLR-3430 and Build changes > > > > On Wed, May 2, 2012 at 1:51 PM, Uwe Schindler <u...@thetaphi.de> wrote: > > > One note: > > > > > > Derby is included since JDK 6 as "JavaDB" together with the JDK: > > > http://www.oracle.com/technetwork/java/javadb/overview/index.html > > > > > > As Lucene/Solr 4 will be using JDK 6 as minimum requirement (in > > > contrast) to > > Solr 3.x (which was JDK 5), can we not simply rely on this version > > shipped with JDK? That would make life easy. And for simple tests that > > version should be enough... > > > > > > > But we dont require *oracle*s implementation as a minimum requirement. > > we also support IBM etc too? > > > > -- > > lucidimagination.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > additional commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
