Embedding the db4o Object-Oriented Database

How to get started using this small-footprint object-oriented database in your embedded system programs.

where <filename> is the path to the file that holds the persistent content
of the ObjectContainer. You put an object into the ObjectContainer using
the set() method. So, we can store our new definition with:

db.set(_float);

which, believe it or not, is just about all you need to know about the
set() method. That one call stores not only the _float DictEntry object,
but all of its contained Defn objects as well. When you call db4o's set()
method, the db4o engine invisibly spiders through the object's references,
persisting all the child objects automatically. Just pass set() the
root object of a complicated object tree, and the whole shebang is
stored at one shot. You don't have to tell db4o about your object's
structure; it discovers it automatically.

To retrieve an object from an ObjectContainer, we locate it with
the help of db4o's QBE (query by example) mechanism. A QBE-style query
is guided by an example, or template, object. More specifically,
you perform a query by creating a template object, populating its fields
with the values you want matched, showing the template object to
the query system and saying, “See this? Go get all the objects that look
like this one.”

So, assuming you want to retrieve our definitions for float, the
process looks something like this:

First, we create the template object, filling the fields we're interested
in with the values we want matched. Fields that shouldn't participate in
the query are filled with zero, the empty string, or null—depending on
the data type. (In the above example, we're simply looking for the word
float in the dictionary. We put an empty string in the pronunciation
field for the templater object constructor, because the pronunciation
is irrelevant to the query.)

Then, we execute the query by calling the ObjectContainer's get()
method, with the template object passed in as the single argument. The
query returns an ObjectSet, through which we can iterate to retrieve
the results of the match.

Adding Indexes

At this point, we can easily create a database, fill it with words
and definitions, and retrieve them using db4o's QBE mechanism. But,
what if we want to experiment with different indexing-driven retrieval
mechanisms? Because the database preserves relationships among the
persistent objects, we can create custom indexing and navigation
structures, place them in the database as well and “wire” our data objects
into those structures.

We illustrate how simple this is by creating two dissimilar indexing
schemes.

First, we create a binary tree. Each node of the tree carries as its
payload a key/data pair. The key will be a text word from the dictionary,
and the associated data item will be a reference to the DictEntry object
in the database. So, we can fetch the binary tree from the database,
execute a search for a specific word in the dictionary and fetch the
matching DictEntry object (if found).

The architecture and behavior of binary trees are well known, so we
won't go into much detail about them here. (In fact, many frameworks now
provide them as standard data structures. We've created an explicit one
to show how easily it can be stored in the database.) Our implementation
appears in Listing 1. It is rudimentary, supporting only insertion and
searching. It doesn't guarantee a balanced tree, but it serves for the
purposes of illustration. The TreeNode class, which defines the structure
of nodes within the binary tree, appears in Listing 2. (Note, we'll
explain the purpose of the calls to db.activate() in Listing 1 shortly.)