Storing serialised objects

As part of my slow and sporadic learn Java activity, I spent some hours last Friday downloading, building and playing with Sleepycat Software’s Berkeley DB Java Edition (commonly referred to as JE it seems).

After a couple of hours I had around five hundred lines of code that would manage a simple database with a couple of indexes. It was pretty straightforward stuff based on the tutorial examples. Re-whacking the code to use the Collections interface was easy and made the application code simpler to follow.

During all of this I’m storing serialised objects in the database, and I’m coming to the conclusion that it’s a mistake to do so. Even if there are solutions to the changing object definition problem, it’s still necessary to implement the solutions. It’s stuff that I just don’t need. The other problem is that the stored objects are serialised Java objects - it’s not simple to manipulate the database from another language, like Python.

In this case I’ll switch to an SQL based database and, I think, my code that uses the database should be better proofed against changes that I need to make in the future (like adding fields). It should be simpler to manipulate the database using multiple programming languages and I hope to be able to iterate over the code much more quickly, which I find very useful when learning.

Admittedly, using serialised objects simplifies some things a little, but the cost seems large - especially when an application is developing rapidly (it’s necessary to throw the database away and rebuild it from scratch a lot).

Given this, what’s the compelling use-case for a serialised object store?