The Adept Object Database

The Adept Object Database - What is it?

The Adept Object Database is a persistent storage and retrieval system for Java Objects. The design goal was simplicity over completeness, and for this reason it's not JDO complient. It doesn't try and compete against SQL by providing a query language. Data from Java objects are persisted directly to the database as binary - and indexed from information in the same class. It is, however, relational with DAO object within DAO objects referred to by reference.

The Adept Object Database - Why is it?

Adept is designed to create shrink-wrapped software packages to be installed by the end-user. One of the primary differences between this environment and application servers with myriads of support staff is the lack of a standard database. Windows boxes will probably have Jet installed, while Unix derivatives will have one of the hashing databases such as berkeley-db. I could not find a reasonable simple stand-alone database library for Java. Now there are good SQL ones, such as HSQLDB, that would have fitted within the Adept concept of leveraging corporate environment skills. But I personally had a hankering to create an object database. Among other things it's a lot faster than a relational SQL database.

The Adept Object Database - When is it?

The Adept Object Database is available now as open source software at SourceForge under the name adze-db. Adze was the earlier name for Adept before I realised that it sounded like spamming software. A new version will be release soon (May 2005) with XML I/O, backups, screen scraping, lazy loading, data migration and database transactions. Oh, you want to know when to use it? Picky, picky...

1. For shrink-wrapped desktop applications.
2. Where data retrieval speed is a primary goal.
3. When you need to persist Java objects (as opposed to matching pre-designed database schema).

It may be more valid to list when not to use the Adept Object Database.

1. When you have in-depth SQL corporate experience you want to use. If you enjoy SQL then why not use it? I recommend HSQLDB for stand-alone Java applications.
2. When the data is to be accessed by multiple sources. Watch this one: it's often better to provide services than allow access to the raw data.
3. When the on-the-fly reporting and investigation tools of relational databases are of use.
4. When your customers have a DBA to maintain the data.

The Adept Object Database - How is it used?

Extend com.marringtons.object.DAO and any public, non-static, non-volatile data is persisted. Indexes are specified as inner classes that inherit from com.marringtons.object.Index. If you want to pass POJOs (plain on Java objects) around there is a package, com.marringtons.object.DTO, for converting data access objects to/from POJOs. It allows a many-to-many relationship between objects. Either can be converted to/from XML with classes from the com.marringtons.xml package. There is a com.marringtons.object.ObjectScraper class that converts objects to/from dictionaries of text. While primarily designed to filling and retrieving from screen forms, it can be used wherever dictionaries or maps are more useful than strongly typed objects.

Limitations of the Adept Object Database

1. Permanence: Once an object is recorded in a database, bad things will happen if the fields change order,  are removed or are added to. Adept does include data migrations tools that can make most changes transparent to the end-user, but the risk exists because developers are used to having free reign with the internal fields of objects.
2. Maintenance: A modern SQL database has utilities and an interpreted SQL command language for a DBA to be able to review and investigate the database internals.
3. Reporting: The application must provide reporting tools since the database itself does not have the transparency SQL provides.

The Competition: Relational Databases

Corporate databases are now almost exclusively table based, sophisticated, optimised, relational databases with an SQL query/update interface. There are also a number of open source equivalents, with MySQL and Postgress providing engine support and HSQLDB as a Java library. Most, including MySQL, require licensing for commercial use. Most, excluding HSQLDB require complicated installation and connection shenanigans.

The Competition: Object/Relational Mapping

Hibernate and EJB 3 are the 2 most promising O/R mappers. They allow a developer to define an object that maps more-or-less directly to a database table. They provide all the facilities of a relational database while maintaining Java objects directly. Because of the complexity of the underlying database, the mapping layers are large, complex and non-trivial. People 'in the know' rave over them.

Personally I am less sure of the benefits. I have used direct JDBC, Hibernate and EJB 2 Entities in similar environments. Because it is best to keep the tiers independent, you end up copying the data into a DTO that more closely matches the service layer's needs than a single table would provide. It is often easiest, fastest and most obvious to do this with SQL and JDBC directly.

Of course the Adept Object Database drops data directly into the object - so the rules change for it.