Odb:c++ object-relational Mapping (ORM) __c++

ODB is a open-source, Cross-platform, and cross-database object-relational Mapping (ORM) system for C + +. It allows to persist C + + objects to a relational database without have to deal with tables, columns, or SQL and with Out manually writing any mapping code. ODB supports MySQL, SQLite, PostgreSQL, Oracle, and Microsoft SQL Server relational databases as AS and c++98/03 1 language standards. It also comes with optional profiles for Boost and Qt which allow your to seamlessly use value types, containers, and smart Pointers from this libraries in your persistent C + + classes.

The following example shows an ordinary C + + class on the "left" and its persistent version of the right.

  #pragma db object
  class person
  {
    ...
  Private:
    friend class odb::access;
    Person () {}

    #pragma db ID
    string email_;

    string name_;
    unsigned short age_;
  };

  class
  Person {
    ...
  Private:




    string Email_;

    string name_;
    unsigned short age_;
  };

ODB is not a framework. It does not dictate how do you should write your application. Rather, it is designed to fit into your style and architecture by only handling C + + object persistence and not interfering With any other functionality. As you can, existing classes can is made persistent with only a few modifications. In particular, a persistent class can be declared without the default constructor, existing accessor and modifier function S can is automatically used to access the data members, and ODB Pragmas can is moved out of the class and into a separate Header, making the object-relational mapping completely non-intrusive. Support for automatic The database schema evolution further allows you to treat ODB or persistent like no other C + + objects SES in your application.

Given The above declarations, we can perform various database operations with objects to the person class using SQLite as An example:

  Odb::sqlite::d atabase db ("people.db");

  Person John ("John@doe.org", "John Doe");
  Person Jane ("jane@doe.org", "Jane Doe");

  Odb::transaction T (Db.begin ());

  Db.persist (John);
  Db.persist (Jane);

  typedef odb::query<person> Person_query;

  For (person& p:db.query<person> (Person_query::age <));
    Cerr << p << Endl;

  Jane.age (Jane.age () + 1);
  Db.update (Jane);

  T.commit ();

For the complete version of the above code fragment as "a" detailed explanation of each line, refer to the Hello Wor LD Example in the ODB Manual.

Using ODB for object persistence has the following advantages:Ease of use.ODB automatically generates database conversion code from your C + + classes and allows to manipulate persistent Using a simple, object-oriented database API.Concise code.With ODB hiding the details of the underlying database, the application logic is written using the natural object Vocabula Ry making it simpler and thus easier to read and understand.Safety.The ODB object persistence and query APIs are statically typed. Use C + + identifiers instead of strings to refer to object and the generated code makes sure database and C + + t Ypes are compatible. All this helps catch programming errors at Compile-time rather than at runtime.Database portability.Because the database conversion code is automatically generated, it's easy to switch from one database vendor to another.Optimal performance.ODB has been designed for high performance and low memory overhead. All the available optimization techniques, such as prepared statements and extensive connection, statement, and buffer CAC Hing, are used to provide the most efficient for each database implementation. Persistent classes have zero per-object memory overhead. There are no hidden "database" Members this each class must have nor are There per-object data structures allocated by ODB .maintainability.Automatic code generation and database schema evolution minimize the effort needed to adapt the application to changes in Persistent classes. The database conversion code is kept separately from the class declarations and application logic. This makes the application easier to debug and maintain.

ODB is highly flexible and customizable. It can either completely hide the relational nature of the underlying database or expose some of the details as required. For example, can automatically map basic C + + types to suitable SQL types, generate the relational database schema for Your persistent classes, and use simple, safe, and yet powerful object query language instead of SQL. OR You can assign SQL types to individual data members, use the existing database schema, and execute native SQL queries. In fact, at a extreme, ODB can is used as just a convenient way to handle results of native SQL queries.

The C + + code that performs the conversion between persistent classes and their database representation is automatically ge Nerated by the ODB compiler. The ODB compiler is a real C + + compiler except that it produces C + + instead of assembly or machine code. In particular, it isn't a Ad-hoc header pre-processor that's only capable of recognizing a subset of C + +. ODB is capable the parsing any standard C + + code.

The ODB compiler uses the GCC compiler frontend for C + + parsing and is implemented using the new GCC plugin architecture. While ODB uses GCC internally, it output is standard C + + which means that you can use any C + + compiler to build your APPL Ication.