views:

10100

answers:

13

Does anyone have a good recommendation for an ORM (Object Relational Mapper) for C++?

Our technology stack is: IDE/C-Compiler = Borland C++ Builder so ideally something that is known to compile with BCC.

We use PostgreSQL as our database and developed our own database abstraction layer using common API to many driver type interface. So ORM need not be database specific although if it is, I'm only currently interested in PostgreSQL aware solutions or solutions with a PostgreSQL's C-Library driver.

One option I have been entertaining is using Perl as an embedded language within our application. Perl has ORM called Rose::DB::Object.

+17  A: 

The ones that I've used are -

  1. Database Template Library
  2. SOCI

DTL is probably the closest to an ORM you can get in C++. And even that is probably stretching it because you still have to know DB column names, do some of the bindings, etc. And getting used to how a simple SELECT statement works will drive you crazy the first few times but makes perfect since later on.

Also DTL works very nicely with STL algorithms.

I've used it with Oracle 9i and MySQL 4.x. It uses ODBC 3.0 underneath the covers. If PostgreSQL has an ODBC driver, I'm sure it would work as well.

SOCI on the other hand is actually nicer in my opinion. You do have to write the SQL yourself, but it is much more flexible in regards to binding (input and output). Also the integration with Boost.Optional is very nice.

It should be noted that true ORM (as most are used to it in .NET or Java) are not possible in C++ as it exists today because there is no way to introspect the classes at runtime. You have to write the binding code in DTL. You'll have to write the binding code in SOCI. But it is trivial code to write. SOCI requires more code, but easier to read. DTL requires less, but harder to read.

Based on your update - I think SOCI would be your best bet then. It is lower level, but you could build your own containers around it. And I believe it is built against PGSQL directly vs. ODBC

Justin Rudd
It is possible to have a Hibernate-like ORM in C++. And you don't have to write the binding code manually. Check the answer about ODB below for details.
Boris Kolpackov
A: 

Take Rose::DB::Object for a spin. I guarantee, you'll never go back to the way you were coding before. It takes so much tedium out of database programming tasks. It will truly be night and day. If you know Perl already, it's a definite win in terms of programmer efficiency. If you don't know Perl, it is the best reason to learn Perl that I know of!

A: 

Thanks Justin but maybe I can clarify. I'm not looking for the ORM to expect a container. I am more than willing to work with the ORM's containers from which I can stub out for my own needs such as iterating over.

The DTL looks enticing but I don't have much STL knowledge to fully grok what they are saying but I did note they are relying on ODBC. In my case I'm interested in either using our own PostgreSQL driver which uses the PGSQL.DLLs or an ORM that has a PostgreSQL based on PBSQL.DLL or PGSQL LIBs rather than ODBC.

Thanks & please correct where I may be derailing the thread. :)

Eric M
I think SOCI would be your best bet then. It is lower level, but you could build your own containers around it. And I believe it is built against PGSQL directly vs. ODBC.
Justin Rudd
Please edit your question to clarify it instead of posting in the answers area.
Doug T.
+1  A: 

I can't recommend embedding Perl into a C/C++ app if you can avoid it. I've done this on a number of projects, and Perl is not easy to work with in this environment. Part of this is due to the reference counting required for all Perl data types, which makes it easier than it should be to leak memory. Aside from that, the API is just very esoteric, and poorly documented. It's definitely possible, but not easy.

dvorak
+3  A: 

Related to the subject, I found LiteSQL, a C++ Object-Relational Persistence Framework. Haven't tried myself but looks like it could be worth checking out.

Touko
+3  A: 

Debea database library (http://debea.net) has native support for PostgreSQL and should compile with BCC just fine.

+6  A: 

I recently found hiberlite which seems to be a very powerful little library. The only downside is that at the moment, it only appears to be sqlite compatible.

I'm going to look at the source to see if I can at least get it to be mysql compatible, as well..

ianmac45
this one rocks!
kRON
It seems like there is no support for transactions, though. (That is, the transactions are only used at statement-level granularity; I cannot perform several object modifications as a single transaction.)
EFraim
A: 

my sqlite3 cpp(c++) orm: http://code.google.com/p/sqlitex/

ddl5200
+2  A: 

Wt::Dbo is a nice template based ORM for C++. Pure C++ and without ugly macros.

+2  A: 

There is also a new open source C++ library : QxOrm. QxOrm is based on QtSql Qt module to communicate with database and boost::serialization to serialize your data with xml and binary format. The web site is in french but quick sample code and tutorial code is in english (a translation is in progress...).

QxOrm
+1  A: 

litesql: http://litesql.sourceforge.net :-)

b0b
A: 

QST ORM: http://sourceforge.net/projects/qstsqltools/

GAS
+2  A: 
Boris Kolpackov
I'm wondering if it couldn't have used templates instead of `#pragma` statements and a pre-compiler.
Omnifarious
That would mean that you will have to add some special database mapping code for *every* data member in every persistent class. The whole point of the ODB compiler is to allow you to automatically persist C++ classes (1) with a few or no modifications and (2) without writing any mapping code manually.
Boris Kolpackov
@Boris Kolpackov: It is possible to construct types (using `::std::tuple` for exmaple) in such a way that you can write metaprograms that automatically generate all the mapping code for you.
Omnifarious
While this is possible theoretically, it will be overly verbose. I am afraid so verbose that it will be actually easier to write registration/serialization code manually. Just imagine how you would specify that a member is an object id, is mapped to column named "ID", and has SQL type "INT" using the tuple approach?
Boris Kolpackov