ODB (C++): History
Please note this is an old version of this entry, which may differ significantly from the current revision.
Contributor:

ODB is an object-relational mapping (ORM) system for the C++ language. It allows an application developer to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any mapping code. ODB supports C++98/03 and C++11 language standards and comes with optional profiles for Boost and Qt which allow an application developer to seamlessly use value types (data-time, string, binary, uuid, etc.), containers, and smart pointers from these libraries in persistent C++ classes. ODB is free software and is dual-licensed under the GPL and a proprietary license. One notable difference between ODB and other ORM implementations for C++ is its automatic generation of the database mapping code and, optionally, the database schema from the C++ headers that declare the classes. This task is performed by the ODB compiler. The ODB compiler is a real C++ compiler except that instead of producing assembly or machine code, it generates portable C++ which can in turn be compiled by any C++ compiler. The ODB compiler uses the GCC compiler front-end for C++ parsing and is implemented using the new GCC plugin architecture. The ODB compiler also provides comprehensive support for database schema evolution, including fully automatic schema migration, support for immediate and gradual data migration, as well as support for soft model changes. The latter feature allows one to work with multiple schema versions using the same C++ classes. The other components of the ODB system include the common runtime library (libodb) and the database-specific runtime libraries (for example, libodb-mysql). The common runtime library defines object-oriented database interfaces that are used by the application developer to perform various database operations on persistent objects. The database-specific runtimes implement these interfaces for concrete database systems and provide support functionality for the generated database mapping code. To achieve high performance, low overhead, and reliability ODB does not use common database APIs, such as ODBC, to access the relational database. Rather, each database-specific runtime library uses low-level, native C APIs that are specific to each database. ODB currently supports the MySQL, SQLite, PostgreSQL, Oracle, and SQL Server databases. Bulk/batch operations are supported for Oracle and SQL Server. The application can also use multiple databases (for example, MySQL, SQLite, etc.) at the same time. Multi-database support comes in the static and dynamic flavors with the latter allowing the application to dynamically load the database support code for individual database if and when necessary. ODB is not a framework. There is no common base type that all persistent classes should derive from nor are there any restrictions on the data member types in persistent classes. Existing classes can be made persistent with a few or no modifications. ODB is also flexible in the level of insulation it provides to the application developer. It can either completely hide the relational nature of the underlying database or expose some of the details as required.

  • object-oriented database
  • multi-database
  • postgresql

1. Mapping

The mapping of C++ classes to database tables is accomplished through a set of custom #pragma directives that are placed in the C++ header file. They allow the application developer to control various aspects of the mapping such as table and column names, C++ types to SQL types mapping, etc. The following example illustrates a typical persistent class declaration:

#pragma db object table("people") class person { ... private: friend class odb::access; person (); #pragma db id auto unsigned long id_; string first_; string last_; #pragma type("INT UNSIGNED") unsigned short age_; };

The ODB-specific pragmas can also be placed outside of the class declaration.

2. Persistence

ODB provides an object-oriented database API that allows the application developer to perform various operations on persistent objects. The following code fragment illustrates the use of the most common operations:

unsigned long joe_id = 1; person john ("John", "Doe", 31); person jane ("Jane", "Doe", 29); transaction t (db.begin ()); // Persist in the database. // db.persist (john); db.persist (jane); // Load from the database. // auto_ptr<person> joe (db.load<person> (joe_id)); // Update in the database. // jane.age (jane.age () + 1); db.update (jane); // Delete from the database. // db.erase (jane); t.commit ();

3. Query Language

ODB provides an object-oriented query language, called ODB Query Language, which is integrated into C++ allowing the application developer to write expressive and type-safe queries that look and feel like ordinary C++. For example:

typedef odb::query<person> query; typedef odb::result<person> result; transaction t (db.begin ()); result r (db.query<person> (query::last == "Doe" && query::age < 30)); for (result::iterator i (r.begin ()); i != r.end (); ++i) { cout << "Hello, " << i->first () << endl; } t.commit ();

Query parameters can be bound to C++ variables either by value or by reference. If desired, native SQL queries can be executed in which case ODB still provides support for parameter binding. ODB also supports prepared queries which are a thin wrapper around the underlying database system's prepared statements functionality. Prepared queries provide a way to perform potentially expensive query preparation tasks only once and then execute the query multiple times.

4. Views

Besides persistent objects, ODB also has the notion of views. An ODB view is a C++ class that embodies a light-weight, read-only projection of one or more persistent objects or database tables or the result of a native SQL query execution.

Some of the common applications of views include loading a subset of data members from objects or columns from database tables, executing and handling results of arbitrary SQL queries, including aggregate queries, as well as joining multiple objects and/or database tables using object relationships or custom join conditions.

Many relational databases also define the concept of views. However, ODB views are not mapped to database views. Rather, by default, an ODB view is mapped to an SQL SELECT query. But, if desired, it is possible to create an ODB view that is based on a relational database view.

As an example, consider a view that returns the number of people stored in the database:

#pragma db view object(person) struct person_count { #pragma db column("count(" + person::id_ + ")") std::size_t count; };

The following code fragment shows how we can use this view to find out how many people are younger than 30:

typedef odb::query<person_count> query; typedef odb::result<person_count> result; transaction t (db.begin ()); result r (db.query<person_count> (query::age < 30)); const person_count& c (*r.begin ()); cout << c.count << endl; t.commit ();

ODB views can be defined in terms of one or more persistent objects, database tables, a combination of the two, or as a native SQL query.

The content is sourced from: https://handwiki.org/wiki/Software:ODB_(C%2B%2B)

This entry is offline, you can click here to edit this entry!