Simple Queries
Here, many of the popular persistence solutions provide finders and Query-by-Example (QBE). JPA or ActiveRecord in Ruby on Rails provide to find objects, for example, via their primary key. Hibernate, like db4o, provides QBE.

In this case an empty object is instantiated (see Listing 1) and if necessary, some fields are set. The query engine will then return all objects with matching fields. Using an empty object or null in db4o, all objects of the class will be retrieved.

This concept was already developed in the seventies by Moshé M. Zloof (IBM Research) and is presented here in a simpler form.

Standard Queries
Query languages like HQL (Hibernate Query Language) or JPQL (Java Persistence Query Language) provide rich keywords as opposed to db4o's Native Queries (NQ).

db4o's Native Queries have other benefits. NQs are notated directly in the programming language. So - unlike HQL or JPQL strings - they're refactorable and type-safe during runtime. This eliminates many query errors (e.g., typing errors), which normally would only be discovered much later. One corresponding example in C# 2.0 and C# 3.0 is given in Listing 2 and Listing 3.

In more advanced - closure/block-capable - programming languages, anonymous delegates can be used to integrate queries seamlessly into the code. There's no need for the developer to learn a new language. The price here is that many advanced keywords such as aggregations or areas aren't available.

Native queries are never actually executed directly. db4o treats the query as domain-specific language capable of reading it during runtime to translate it into another language (SODA) and execute it afterwards. This is a powerful concept that we'll continue to encounter in dynamic languages like Ruby.

Only Microsoft's LINQ was able to realize both benefits: A complex query language in the programming language with a high variety of keywords. This undertaking is easier if you have the option of changing the language correspondingly as happened in C# 3.0. Here, in some areas LINQ is still significantly ahead of db4o, JPA/EJB, and Hibernate.

Complex Queries
In Hibernate there's the so-called Criteria API for complex queries. Here object trees are built, constrained, and then executed. Listing 4 shows a manual example where all stored cat-objects are checked. Eventually only the ones starting with Fritz are to be chosen.

SODA, surprisingly enough, is a very similar API that's older than the Hibernate Criteria API. Since it started, SODA was open source and uploaded to sourceforge.net by db4o chief software architect Carl Rosenberger (a member of the EJB 3 JSR expert group) and has evolved through community contributions. Listing 5 shows a SODA Query.

More Comparative Parameters
We'll illustrate below more of db4o's features and compare them to other popular solutions.

Performance
As shown in many reports, db4o can be a very fast but at times fairly slow database system.

A scenario where db4o is strongest is in Seagate's hard disks using single-threaded access in the embedded mode. In most cases db4o is significantly faster than relational database management systems and OR-Mappers.

However, if the application is a Web application with many users triggering multithreaded queries via the application server, db4o can't keep up with relational solutions. In this case relational DBMS can be much faster. The reason for this is in db4o's design, as mentioned in the section about Transactions.

Client/Server & Replication
It's very easy to start db4o in client/server mode. The only difference lies in creating an ObjectContainer that can be set up as a client or a server. This makes db4o an ideal choice for scenarios where the client collects data and sends it to the db4o server.

For these and similar scenarios, db4o provides two replication modes:
1)  Using just a few lines of code, objects can be replicated either uni- or bi-directionally between db4o server instances.

2)  This is even possible with relational databases. With specific settings and Hibernate mappings, db4o data can be transfered to all databases that Hibernate supports: The perfect tool to combine both worlds.

Callbacks
As an equivalent to triggers on the database system level, there are callbacks on the object level that make it easy to hook into the object lifecycle.

This tool is available in both Hibernate and Ruby on Rails with before_validation() or after_save().

db4o's approach is easier. Here we have internal (in the data objects) and external callbacks. Internal callbacks are methods in the class like onDelete(), onActivate(), canUpdate(), and canDeactivate(), which are automatically detected and executed via reflection. This makes it easy to influence the persistence process in many ways such as executing object validations or setting fields.

In some cases, it's desirable to act on object state changes without a class so db4o introduced many external callbacks in version 6: queryStarted, Creating, Activated, Updated, Deleted, Committed, etc. They are simply registered with the ObjectContainer and make db4o an easily upgradeable and powerful persistence tool.

Conclusion
Working with db4o is incredibly easy and a natural extension of OO languages. Persistence developers will be thrilled by db4o's transparent and simple administration.

db4o also handles some of the most important schema changes transparently. Field types can be easily modified and exceptions can be easily added or deleted, without any drama. The database does what's expected, and class fields and class names can be adapted or migrated with just one line of code.

In a Hibernate/MySQL scenario, we would encounter many exceptions.

Nevertheless there's a downside to db4o, like the price paid for easily storing object data directly in a native format. There's another example besides the scalability drawbacks: Database management, data analysis, or OLAP reporting is done more expertly in relational solutions. This is where relational products show more maturity in having an architecture designed to please the enterprise application.

In conclusion we recommend that anyone interested in databases should evaluate db4o and compare it to established database solutions since a DAO only requires a little effort but quickly shows db4o's benefits and limits.

db4o is provided under a dual-license model like MySQL. Private non-commercial or open source GPL-use is free. There's a third license option similar to classpath licensing called dOCL so db4o can be embedded into other kinds of open source products, an appealing option for open source developers.

Finally it's worth mentioning that the Object Database Management Group (ODMG) - which also standardized OQL many years ago - is working on a "fourth-generation" standard. It remains to be seen how this contribution will influence the database system world.

References
  •   William Cook and Siddhartha Rai. "Safe Query Objects." 2005.
www.cs.utexas.edu/users/wcook/
  •   William Cook and Carl Rosenberger. "Native Queries for Persistent Objects."
www.cs.utexas.edu/~wcook
  •   Pieter van Zyl. "Object-Oriented Databases and Object Relational Mapping Tools in the Persistence Layer." 2005.
http://espresso.cs.up.ac.za/
  •   http://blog.hibernate.org/cgi-in/blosxom.cgi/2007/05/23#in-defence.
  •   http://blogs.tedneward.com. June 11, 2007.
  •   Dave Thomas and David Heinemeier Hansson. "Agile Web Development with Rails." Pragmatic Programmers. Second Edition. 2007.

This article was originally published in the German publication DB-Spektrum.