Build an object database - JavaWorld January
2000
Tutorial Details:
Build an object database
Build an object database
By: By Merlin Hughes and Michael Shoffner
Construct a frontend to translate between Java objects and relational database records
ne of the great strengths of Java is its ability to automate tedious programming tasks. For example, in the realm of I/O, object serialization automates the encoding of an arbitrary object as a stream of bytes. It could be done manually, but serialization makes it much more accessible and effective. Similarly, in the realm of networking, RMI (Remote Method Invocation) automates network requests between objects. That, again, could be done manually, but RMI makes it more accessible and effective. Finally, in the world of XML, work is under way to automate the generation of Java maps of XML document types, which will provide automated facilities for encoding and decoding XML documents. Again, much better than doing it manually.
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
One notable gap in this capability is the realm of databases. In this article, we will present our first go at overcoming this limitation by providing automated transformations between Java objects and records in a database.
(Some credit for this article must be extended to JavaWorld reader Alasdair Gilmour, who graciously pointed us in the direction of accessing private object fields.)
Note: The article's full source code can be downloaded from Resources .
Terminology
Let's first get some terminology down. You see, I'm a firm believer in flat files, binary editors, and linear searches. There's really nothing you can't do with them. Since I'm now venturing into the scary world of databases, I want to make sure you know what I mean by ftang when I say ftang.
A database is a collection of tables. A table is a collection of records. A record is a collection of fields. Fields are the basic units of information in a database.
So, a database is a big bad backend system containing all of your information. Remember, information is power. A table is a specific subset of information of a particular type: for example, a table of all the employees in your company. A record is a single row within that table: for example, all information about a particular employee. Finally, a field is a particular datum within that record: for example, an employee's expendability rating.
In this article, we want to map between database records and Java objects. That means we want to be able to automatically translate between a Java User object and a particular record within, for example, an employees table in a database. Consequently, the name variable of the Java object will be mapped to the name field of the database record, and vice versa.
To accomplish this, we could simply serialize the Java object and throw the resulting binary blob into the database. But that's no fun. It does not lend itself to convenient access from anything but a Java program. In particular, we lose interoperability and we lose human accessibility. So we're not going there.
Architecture
Let's look at the 33,000-foot view of storing a Java object in a database:
Vivisect a Java object to determine all its fields and their values
Store those fields and values into the backend database
Dropping rapidly to sea level, we have a couple of options for vivisecting the object: reflection allows us to programmatically query the object's public fields, and serialization allows us to automatically encode all the fields of the object. Alternatively, a public interface would allow the object to decide on its own encoding. Similarly, we have a variety of options for storing the fields in the backend database: JDBC (Java Database Connectivity), flat files, maps, and so on.
Conveniently, the logical separation between vivisection and cold storage provides a convenient break between this article (mine) and the next (Michael Shoffner's). I'll be your vivisectionist on this little tour; Mike, your mortician. I mean, database consultant. The separation also provides a convenient variety of runtime configuration options.
Having briefly outlined the broad division of labor, I'm now going to nail down two interfaces that describe the processes:
ObjectStorer . This interface describes the frontend object database process: scattering a Java object into fields within backend storage, and gathering those fields back into a Java object.
ObjectStorage . This interface describes the backend object database process: storing object fields in a database and retrieving them from the database.
The object storage architecture
To actually make use of the system, you must connect an ObjectStorer with an ObjectStorage . So, we next need to nail down the datastructures that will be communicated between these interfaces:
StorageFields . This class encapsulates information about the object being stored, including the names, types, and values of all its fields. An ObjectStorer will hand the information to an ObjectStorage for placement in the database.
RetrievalFields . This class encapsulates information about the record that was retrieved from the database, including the names and values of all fields. The difference from StorageFields is that the backend need not maintain type information about the fields; that is automatically determined during the retrieval process.
This is about as far as I can go without getting my feet wet, so I guess it's about time to code ...
Implementation
I start with the code for the architectural classes. After this, I'll go through a reflection-based object storer, a serialization-based object storer, and finally a map-based object storage so that we can check that things are working out.
Interface ObjectStorer
The ObjectStorer interface leads to the frontend of our object storage system:
import java.io.*;
public interface ObjectStorer {
public void put (Object key, Object object) throws IOException;
public Object get (Object key) throws IOException,
ClassNotFoundException, IllegalAccessException, InstantiationException;
}
The API is quite simple: You insert an object into storage with the put() method. Along with an object, you specify a key with which it will be stored in the backend. The meaning of this key is backend specific. For a database, it might identify a particular record within a table. For a flat file, it might identify the index number. Any existing object is removed. If you put null into storage, then the record is emptied.
Similarly, you retrieve an object from storage with the get() method, specifying the key under which the object was stored. Again, the key is backend specific. The result has type Object ; you must cast it to the particular type that you expect. The type returned depends on the backend and what was originally stored there. If no record is found, then null is returned.
Various exceptions may be raised, depending on whether there is an I/O error communicating with storage, or if there is a problem constructing a retrieved type.
Interface ObjectStorage
The ObjectStorage interface leads to the backend of our object storage system:
import java.io.*;
public interface ObjectStorage {
public void put (Object key, StorageFields object) throws IOException;
public RetrievalFields get (Object key) throws IOException;
}
The API is again quite simple: An object, represented as a StorageFields datastructure containing all the object's fields, is placed into backend storage under the user-specified key. If object is null , then the key should be removed from the database.
Similarly, retrieval from the database involves extracting an object of type RetrievalFields corresponding to the user-specified key.
Class StorageFields
The StorageFields class represents an object's fields that are to be placed in backend storage. Rather than bore you with details, I'll just provide a skeleton of the API to this class. Internally, it's a few maps and lists. (See Resources for the complete source code.)
import java.util.*;
public class StorageFields {
public StorageFields (String className) ...
public void addField (String field, Class type, Object value) ...
public String getClassName () ...
public Iterator getFieldNames () ...
public Class getType (Object field) ...
public Object getValue (Object field) ...
}
The constructor for this class accepts the class name of the object it is representing (for example, org.merlin.Employee ). The addField() method then allows object fields to be added. Each field is fully specified as a name ("value," for example), type (represented by the appropriate Class object), and value. Primitive values are wrapped in the appropriate holder (for example, java.lang.Integer ).
To query this class, getClassName() returns the name of the represented class and getFieldNames() returns an iteration of the field names. For each field name, getType() returns the corresponding type, and getValue() the corresponding value.
Now, there are a few caveats involved in storing an object from this representation. First is the issue of the class name. To recreate an object from its fields, we must (at the very least -- I'll discuss this more along with serialization) know its class name. This information should, therefore, typically be stored along with the fields. However, it may be that this information is implicitly obvious. For example, a particular table may only ever hold org.merlin.Employee objects in bondage, in which case the information need not be stored along with each record; it can instead be retrieved based on the implicit context.
Next we have the issue of duplicate field names. If a superclass and subclass happen to declare the same particular field, then we would end up with a clash of names in the fields to be stored. To overcome this, the storer must explicitly rename dupl
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Build an object database - JavaWorld January
2000
View Tutorial: Build an object database - JavaWorld January
2000
Related
Tutorials:
 Will Big Blue
eclipse the Java
tools market?
Will Big Blue
eclipse the Java
tools market?
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
Create your own type 3 JDBC driver, Part 2
Create your own type 3 JDBC driver, Part 2
|
J2SE 1.4
breathes new life into the CORBA community, Part
3
J2SE 1.4
breathes new life into the CORBA community, Part
3
|
My kingdom for
a good timer!
My kingdom for
a good timer!
|
Make the Java-Oracle9i
connection
Make the Java-Oracle9i
connection
|
Impressive
!
Impressive
!
|
Maybe the future UI design of choice
Maybe the future UI design of choice
|
Extensible Code Generation with Java, Part 1
Extensible Code Generation with Java, Part 1
Code generation is a key new trend in engineering, one that you need to understand well. The reason is simple: today's modern frameworks are extremely code-intensive. Using a code generator to build the code
|
Simple classes for JDBC
Simple classes for JDBC
|
Framework for Java Database Connectivity
What is Framework for Java Database Connectivity?
The Framework for Java Database Connectivity (JDBC) was implemented to demonstrate the ease with which a JavaTM application may be designed to access a source code repository using a relational query lang
|
Using CachedRowSet to Transfer JDBC Query Results Between Classes
Using CachedRowSet to Transfer JDBC Query Results Between Classes
The Java Database Connectivity (JDBC) API provides developers with an interface to a SQL database server, such as MySQL or Oracle. Central to any JDBC application is the java.sql.ResultS
|
The power of table-oriented programming
The power of table-oriented programming
When object-oriented programming languages began to be used in enterprise applications, designers had problems fitting the object-oriented model with the relational model. In the object-oriented model, data is enca
|
Simple Object Persistence with the db4o Object Database
Simple Object Persistence with the db4o Object Database. db4o has been chosen for applications in embedded systems in which zero administration, reliability, and low footprint are critical features. In Germany, BMW Car IT, for example, uses it in an embed
|
Object-Oriented Language: Java / APIs (Classes & Libraries)
The Java Platform APIs are a set of essential interfaces that developers need to build their Java applications and applets. All Java Platfrom APIs are open and extensible, and are created by JavaSoft and industry-wide specialists in each target technology
|
Hibernate simplifies inheritance mapping.
Learn three easy-to-implement strategies to map class hierarchies. Hibernate is an object-relational mapping and persistence framework that provides a lot of advanced features, ranging from introspection to polymorphism and inheritance mapping.
|
Tech Tip: Using the Varargs Language Feature
Have you ever needed to pass in many instances of the same object type to a method, but you don't know at compile time how many instances there will be? Find out how the new varargs language feature makes it easy to handle situations like this.
|
Connecting to the Database Using JDBC and Pure Java driver
Connecting to the Database Using JDBC and Pure Java driver
Connecting to the Database
JDBC Driver
In our search engine we are using MySQL database server and MM.MySQL Driver for connecting our application to the database. MM.MySQL Driver is
|
JLAN Server v3.5 - Database Filesystems
*JLAN Server* is a high performance Java based file server supporting Windows file sharing (SMB/CIFS), NFS and FTP protocols.
|
New Technical Articles: 64-bit Programming on Solaris 10 OS for x86 Platforms
Four technical articles describe the new Sun Studio 10 software's 64-bit programming features on the Solaris 10 OS for x86 and AMD64 platforms. Important issues regarding the AMD64 ABI (Application Binary Interface), debugging, migration to 64-bits, and p
|
|
|
|
