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.

Is it possible to get addicted to a programming language? Maybe it is. If you look at the Java community, you find a passion I’ve hardly known of any other language. But that doesn’t always have to be a good thing. Passion (and addiction) can go as far as completely ignoring anything else out there. I’ve realized that while reading Rod Johnson’s awesome book “J2EE Development without EJB”. He writes about how Microsoft looked at the flaws of the J2EE to find a better and easier model for its .NET implementation. While not being perfect, it certainly looks easier. So Microsoft tried to learn from what went wrong with similar technologies, but Sun wouldn’t do it the same way, it seems. EJB 3 looks promising, but it’s still a long way to go and I doubt (well, a little at least) that it’s going to be a huge success. Simple yet powerful tools like Hibernate and Spring have come a long way to prove that it’s possible to develop enterprise level applications without the huge overhead implied by a J2EE container. They’re being embraced by the Java community, but get devalued elsewhere. This got me thinking about why it’s so hard to open up to change, gaining more productivity and move from heavyweight to lightweight application architectures. I haven’t really come to a conclusion yet, since it’s hard to follow the arguments you get to hear. They tend to not making any sense at all. But I have a good feeling that this might change in the future. Sure, there still are people out there saying CORBA is the best thing since sliced bread, but even Michael Jackson has some die-hard fans left.

I find it quite weird, how people can get religious about stuff. IntelliJ IDEA is better than Eclipse is better then NetBeans is better than Emacs is better than vim. Servlets vs. PHP vs. Ruby on Rails. Well, I’m using Eclipse and vim, and I like to use PHP as well as any other suitable framework for web development. It just depends on what I want. The right tool for the right job. Yeah, I know that this is nothing new really, but sometimes I get the feeling that people just lose track and get lost in unimportant details of why they favor this over that. That’s the downside of addiction. You tend to ignore anything else and if you’re on cold turkey, you wish everything would just be the way it used to be.

So what’s the deal here? Javaddicts would like to tell stories of Java development as well as stories about working with great tools like Ruby on Rails as well as working with Objective-C and Cocoa on Mac OS X. Having a broader knowledge of tools and programming languages doesn’t automatically make you a better software developer, but you get a better sense of choosing the right tool for the right job.