Compared to languages popular for web development, such as Java, Python or Ruby, no decent Object Relation Mapping (ORM) framework exists for C++. “Good” ORM solutions (at least measured by popularity) are Java’s Hibernate library (and now JPA) and Ruby’s ActiveRecord library. These tools do not just map single database tables onto classes, but also map relations between tables onto native collections and datastructures. In this way you can navigate an object and its related objects without explicitly defining SQL queries.

Strangely, while the flexibility of C++'s templating system rightfully deserves its share of praise (and criticism) to describe new Domain Specific Languages (for example Boost.Spirit), some developers are suggesting that the lack of reflection excludes a nice ORM layer in C++.

To be fair, it was not until we discovered the hiberlite library, that we realized that the C++ template system can make up for what it lacks in terms of reflection.

So we started implementing Wt::Dbo (database objects), which is now working out very well. Similar to hiberlite, Wt::Dbo uses a single template function to define the correspondence between the fields in a class and columns in a table, but provides a far more conventional relational mapping than hiberlite does, with support for 1-N and M-N relations.

The following is an actual code fragment that shows how the comment class in the code of this blog is mapped to a database table :

For clarity our data are public member fields, but you can use accessor methods to your own taste. The persist() method can also be defined as a free standing function outside of your class definition.

The trick behind this mapping solution is that the library defines several actions: to create the schema, to prepare statements, to insert, update and load objects and to propagate transaction results. These actions are applied to an object, by visiting the object and hence its data members using the action parameter of the persist() function.

This results in an ORM solution with low runtime overhead (no virtual method calls or reflection), low developer overhead (no need to manage a separate mapping file) and maximum flexibility (everything is defined in C++ as opposed to a separate XML file).

A key class is ptr<C> : it is a smart pointer class that also implements book keeping for persisting the referenced object. There are two reasons why a smart pointer is a natural solution in an ORM framework. First ownership of records is not always clearly defined in a database (does a user own a comment, or does the post own a comment ?). Secondly, we want to make sure that we load only a single transient copy of a persisted object. Explicitly managing this in your application (keeping things independent) is burdensome and smart pointers are, well, smart.

db::ptr<C> is mostly compatible with any other smart pointers (such as std::shared_ptr<C>) except for one big difference : dereferencing the pointer returns a const reference to the pointed object. To obtain a non-const reference, you need to call the modify() method. This allows the library to keep track of object modifications (dirty checking).

Let’s look at the code that adds a new Comment to a Post:

Obviously, there is much more to be said about Wt::Dbo than just these basics. The library is pretty young but already very well useable. Now is an opportune time to reflect on its form and perhaps still change things.

Currently, Wt:dbo contains the following functionality:

We are at the moment busy with documenting the whole API, before merging the library into the public branch, which we expect to do over the next few weeks.