ODB - compiler-base ORM for C++

I am pleased to announce the initial release of ODB.

ODB is an open-source, compiler-based object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any mapping code. For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  #pragma db object
  class person
  {
    ...

  private:
    friend class odb::access;                                           
    person ();

    #pragma db id auto
    unsigned long id_;

    string first_;
    string last_;
    unsigned short age_;
  };


ODB is not a framework. It does not dictate how 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 see, existing classes can be made persistent with only a few modifications.

Given the above class, we can perform various database operations with its objects:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  person john ("John", "Doe", 31);
  person jane ("Jane", "Doe", 29);

  transaction t (db.begin ());

  db.persist (john);
  db.persist (jane);

  result r (db.query<person> (query::last == "Doe" && query::age < 30));
  copy (r.begin (), r.end (), ostream_iterator<person> (cout, "\n"));

  jane.age (jane.age () + 1);
  db.update (jane);

  t.commit ();


The C++ code that performs the conversion between persistent classes and their database representation is automatically generated 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 is not an ad-hoc header pre-processor that is only capable of recognizing a subset of C++. ODB is capable of handling 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, its output is standard C++ which means that you can use any C++ compiler to build your application.

ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.5.x, MS Visual C++ 2008 and 2010, and Sun Studio 12. The dependency-free ODB compiler binaries are available for all of the above platforms. The initial release supports MySQL as the underlying database. Support for other database systems is in the works.

More information, documentation, source code, and pre-compiled binaries are available from:

http://www.codesynthesis.com/products/odb/
closed account (EzwRko23)
Nice software, but as a business - a total failure:

1. GPL for library code = not really free.
2. No pricing information on the site.
3. Who uses C++ for database access anyway? You put yourself into a niche.
4. Only MySQL supported - you put yourself into a narrower niche even further (MySQL is a toy database used mostly for powering blogs and forums, which is a domain of PHP).
5. Code preprocessing required = forcing your users to modify their build chain. Bad idea.

and the last, but the most important:
6. How are you going to compete with Hibernate/NHibernate, which has more features, is less intrusive, has more liberal license and is widely accepted by enterprise?

If you get 0.01% of ORM market share you'll be very lucky.

Last edited on
4. Code preprocessing required.

What's wrong about code preprocessing?
closed account (EzwRko23)
It adds one more brick to the great PITA which is building a large C++ application.

I believe they are trying the Java ORM (object-relational-mapping) concept and applies to C++. This is a good initiative but then it remains to be seen how the C++ community "warm" up to this though.

There are a lot more Java-based idea already but not yet ported to the C++ community I believe.
closed account (S6k9GNh0)
xorebxebx,

1. There's hardly a downside to the GPL license. Preventing yourself from getting screwed is a smart measure to take.

2. The code is free to take as long as you abide the license. If you want a proprietary license, you may contact them which is actually on the website under Contact.

3. Why not use C++ for database access?

4. He's already mentioned that they're in the process of adding new databases. Libraries do consume time after all.

5. meh

6. Well, the fact that its using C++ attracts a LOT of people who don't like Java or the even worse .NET framework.
Last edited on
Hi computerequip, the fact remains C++ community still prefer to go low level enuff. There just ain't enough "business-centric" (I coined this term myself :) API coming out from C++ Open Source communities.

When I say "business-centric" API I give a few examples. I want an easy way to "talk" to M$ software file formats, Adobe PDF, 2D, 3D imaging, printing, XML parser, index, search, http, ftp, telnet, scp etc etc.

Granted there are C++ Open Source projects going on for each of the realm I mention above but they seem scattered so as to speak. I would like them to come into one place.

Apache Software Foundation is one place where almost all Java-based Open Source projects are released there. I only need go to a SINGLE place browse and viola I found a library ready to use! There are C++ but they are the minorities while the rest are dominated by Java.
closed account (EzwRko23)
1. Using a GPL license for a product that is intended as a library is a misuse of GPL. GPL is to protect that if you modify the original, GPLed product, the license holder would get your modifications. But the application with an ORM layer is hardly a modification of the ORM. It is a separate application. Yet, GPL requires you to open-source it. That is why you have LGPL for libraries.

2. If I want a prioprietary license, I go to the shop, where the prices are listed. No time to ask everyone for information. This is not respecting your not-yet-customers.

3. C++ is mostly used for low level stuff or desktop apps / games. They don't use databases. The ones that use databases are usually web or network oriented - this is not a domain of C++, this is a kingdom of Java/PHP/.NET/Ruby/Python.

6. For serious businesses, it is irrelevant if someone "likes Java/.NET or not". The important thing is how much it costs to deliver added value to their customers.
I had intentions to ignore this thread, but meh. I can waste a few seconds of my time at this point.

1. http://www.gnu.org/licenses/why-not-lgpl.html
^Read this. ;)

2. I suspect that there's a good reason the costs for proprietary licenses are determined on a case-by-case basis. If there is no good reason, then no excuse, then.

EDIT: I had removed #3 because I did deem it to be too simplistic an argument, but since xorebxebx noticed it, I will add it back.
3. What do you mean that games don't use databases? Clarify, would ya?

6. If enough people don't like Java/.NET, programmers for the job may become harder to find and more expensive, hmm?

-Albatross
Last edited on
closed account (EzwRko23)
1. There is one problem there: I can't use your library to produce a product that has less restrictive license than GPL (e.g. BSD like). I'm forced to make everything GPL (I can dual-license my part of code, but this is pointless, because it is not standalone). GPL is a license saying "I don't want to make money from it, but I also don't want you to make money from it".

3. You are nitpicking here - they use, but not relational and not through ORM layer. Usually very simplistic things to store points / level state etc.

6. Good reasoning, but this is not what actually happens. Actually if people are free to choose, most of them prefer programming Java over C++. Just see, what are most open-source projects created in.
Last edited on
1. That's right. If he used the LGPL, he wouldn't be able to charge people for the commercial use of his library nearly as well as if he used the GPL (which he did, it seems). If you want to change the license for your product... isn't there a contact link somewhere on that page?

3. Those are still databases, I'm sorry. Not relational and definitely not through an ORM layer. But.
(I'm sure, by the way, that there are pretty good to excellent networking libraries for C++).

6. Statistical evidence link required, please. (Although that second-to-last bit makes sense. It's quite hard to shoot yourself in any appendage with Java).

-Albatross
Last edited on
closed account (EzwRko23)
1.
If you want to change the license for your product... isn't there a contact link somewhere on that page?


What for would I use it if better packages exist on BSD-like licenses?

Quote from: http://lwn.net/Articles/172128/:

But dual-licensed software should not be seen as free software with some commercially inconvenient strings removed. It is proprietary software, with all the risks that come with the proprietary model.



6. Sourceforge statistics: http://www.cs.berkeley.edu/~flab/languages.html; a little outdated, but the trend is clearly visible. Langpop.com has also some recent statistics from Ohloh and Google Code
Last edited on
1.
If better packages exist on a BSD-like license, then I like you would most certainly go for it rather than the other product (unless this one really has something good to boast).

6. "Access restricted", but I was able with some URL hacking to access the chart:
http://www.cs.berkeley.edu/~flab/languages.png
I can't help but wonder something, though. Even as I note that Java was at some point being used more on Sourceforge by a 0.23%, what sort of libraries are being created for Java? Would you perchance know? I won't ask for a statistic.

EDIT: Haha! Objective-C is fourth from the bottom of the list!

EDIT2: I win?

-Albatross
Last edited on
Topic archived. No new replies allowed.