Javaddicts

While working with Hibernate I stumbled over Derby. Derby has had quite a few owners (Cloudscape, hence the original name before it was contributed to Apache, Informix and then IBM) and has finally landed on planet Apache Foundation and found its way into the incubator.

It’s not officially on the list of databases supported by Hibernate (I’m using Hibernate v3.0.x, it’s a no-go with v2.1.x), but a dialect is available anyway. So I gave it a shot and I was amazed about how easy it was to use. Just put the jar into the class-path of choice (Ant might be the best idea ;) and configure Hibernate accordingly:

hibernate.dialect=org.hibernate.dialect.DerbyDialect
hibernate.connection.url=jdbc:derby:<dbname>;create=true
hibernate.connection.driver_class=org.apache.derby.jdbc.EmbeddedDriver

Insert for <dbname> whatever database name suites you. It’s frickin’ easy. And it just works neatly. Derby is quite an impressive piece of Java work, albeit a little slower than “the big ones”. But its embedded-ness makes (you get a fully featured relational database engine with all features you might ever wish for just by embedding a single jar) it quite easy to use, either in or out of the container. And at least for development and testing purposes I don’t need the fastest database ever.

If you want to be more in control of where your database is put (the default is to put it in whatever your current working directory is), just add a specific path:

hibernate.connection.url=jdbc:derby:/home/derby/ponydb

or, if you’re on Windows:

hibernate.connection.url=jdbc:derby:c:/windows/ponydb

That was easy, was it? So now you can go ahead and create your schema or let Hibernate do the dirty work for you via

hibernate.hbm2ddl.auto=create-drop

When you configure Hibernate and fetch your SessionFactory, it opens a “connection” to the embedded Derby instance. With the JDBC property create set to true, Derby will just create the database for you without any hassle. Might not be the best option for a production level release, but for testing purposes this is perfect.

Using it that way makes Derby a perfect companion for easy working with your persistence layer. If you use your persistent classes in unit tests, then Derby is a nice way to do that. There might be some arguing that you shouldn’t use a real database for unit-testing purposes, but I’d be lost without tests that assure that my mapping files are correct. And Derby filled that empty spot quite nicely.

A database doesn’t go off without any restriction and so Derby has some, of course. The most remarkable one is a restriction of column names to 30 characters. That shouldn’t be a big problem, if you have a well planned schema, but sometimes this gets in the way. Another issue is the restricted length for constraints. 18 characters isn’t that much and sometimes Hibernate seems to choose longer names for constraints.

So that’s it for today. There’s really nothing more to do when using Derby with Hibernate. But stay tuned for more Derby related stuff. I’ll have some deeper look at what you can do with it. Using it inside a container and as a server database is going to be interesting.

This entry was posted on Friday, April 22nd, 2005 at 8:44 pm and is filed under Development, Java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.