Build an object database, Part 2: Object storage backend

Implement relational database storage for Java objects

By Michael Shoffner and Merlin Hughes, JavaWorld.com, 04/07/00

Tools do exist to help with this process, usually at a "generous fee" (with respects to the late Curtis Mayfield). Sometimes the tools are necessary, especially when mapping from an existing relational data model to an object model. However, when the relational model is not set in stone, it is possible to let the object model drive the relational model, allowing storage options to surface closer to home.

TEXTBOX:

TEXTBOX_HEAD: Build an object database: Read the whole series!

• Part 1: Construct a frontend to translate between Java objects and relational database records
• Part 2: Implement relational database storage for Java objects

:END_TEXTBOX

The most obvious solution: serialize each Java object using the object streams and slap the result into a database as a binary blob. While this is certainly a valid option and the JDBC explicitly supports it, blobs cannot be readily manipulated (or even read) by anything other than other Java applications. So interoperability, along with human readability, go out the door.

The relational storage backend we'll build alleviates this data- interoperability problem. Our backend actually creates relational tables for each class and maps each instance's variables into them as columns, creating a sort of poor man's object-relational mapping, if you will. (To download this article's complete source code, go to Resources.)

Framework overview revisited

The object-storing framework introduced in the January Java Step by Step time divides the work of persisting Java objects into two tasks:

1. Frontend: Scatter the object into its fields, preserving its type information -- the responsibility of an ObjectStorer implementation.
   
   
2. Backend: Store the values of the fields along with type information -- the responsibility of an ObjectStorage implementation.

Figure 1. The object storage architecture

The object-storing framework enables object storers and object storage implementations to vary independently. The object storer doesn't care how the object storage implements its storage behavior, and the object storage doesn't know that the object storer exists. This is as it should be.

The ObjectStorer interfaces look like this:

 public interface ObjectStorer {
  public void put (Object key, Object object) throws IOException;
  public Object get (Object key) throws IOException,
                                        ClassNotFoundException, 
                                        IllegalAccessException, 
                                        InstantiationException;
}

In the January Java Step by Step, Merlin provides implementations of this interface -- most notably a SerializationStorer.

In this article, we'll complete the framework by implementing the ObjectStorage interface, as seen below:

 public interface ObjectStorage {
  public void put (Object key, StorageFields object) throws IOException;
  public RetrievalFields get (Object key) throws IOException;
  } 

The ObjectStorage interface uses the StorageFields and the RetrievalFields classes to pass information about fields that are stored and retrieved, as we'll see next.

Class StorageFields

As you'll no doubt recall, the StorageFields is a collection of the scattered fields, as well as the stored Java object's type information. The ObjectStorer implementation hands an instance of this class to the ObjectStorage implementation as a parameter to the put() method.

Class RetrievalFields

The RetrievalFields class is a collection of fields returned by the ObjectStorage implementation in response to a get() call. It is practically the same as the StorageFields class, except that there is no need to explicitly state type information since it is represented by the class of the object being returned.

We'll call our ObjectStorage implementation class SQLObjectStorage.

SQLObjectStorage's data model and constraints

Before we delve into the code, let's outline how our SQLObjectStorage's relational data model will work.

Figure 2. SQLObjectStorage's data model

The main concept behind this extremely simple data model is: SQLObjectStorage creates a relational table for each class to be stored in the database. SQLObjectStorage then stores instances of a given class in the table created to correspond to that class.

Each table includes a set of columns that correspond to the fields defined in the class. SQLObjectStorage dynamically creates tables and columns using a database-specific mapping from Java types to column types supported by the database.

A bit of overhead information -- the mapping from each key to its respective instance in the database -- is kept in the database in addition to the stored instances. To achieve this end, SQLObjectStorage creates a key column in each table to key the instances therein. It also creates a special key table in the database to store every key and the table where it resides.

In addition, SQLObjectStorage imposes the following constraints:

• Each database's keys are unique: A key uniquely identifies an object in a specific database. If a key/value pair exists in the database and another value is entered with the same key, the new value replaces the old value.
• There are no duplicate entries per key: Each key will store against only one value.
• One table exists per primary class type (classname): Each class is stored as an instance of its primary class, with all of its fields as well as superclass fields flattened out into the columns of the table that bears its name.
• Class and field names are escaped: In order to avoid illegal database characters, encode class names with escape characters to get table names. The same process applies to mapping fields to column names.
• Values are escaped: Field values are escaped to avoid problems with SQL statement syntax.

Abstract class SQLObjectStorage

So now we come to the ObjectStorage implementation. We'll look at just the important methods here. (For the complete source code, see Resources.)

First, we look at the ObjectStorage-interface method implementations, starting with put().