Zitat von Michael Powell
Additionally, given some language "features", perhaps "limitations" if you will, of C++11, as contrasted with a C# let's say, I also want for any ORM code, whether meta-programmed or not, to be as non-intrusive to the domain model as possible. I've seen a ton of code that have persist methods, friend access, macros, and such.
Sounds like a tall order I know. Call me spoiled on the "niceness" of .NET, Reflection, and so on.
while there is no out-of-the-box solution for ORM currently, I do think that Boost.Serialization provides the reflection necessary to build one. the proposed introspection libraries that have been referred to as "too templat'y" try to provide introspection on the entire C++ object model. for ORM, especially for losely-coupled ORM that doesn't automatically create a database schema, you only need reflection of data fields, their types, class inheritance structure and the like, which the Serializable concept of Boost.Serialization does provide [1]. also see the use of name-value-pairs, which can refer to database fields in ORM [2]. Building a Serialization Archive that collects all the fields, field names and types, including aggregate types, so you can iterate through them dynamically as you might be used to from .NET, should be easy enough. However, for a really generic solution to C++ ORM there are a few more problems to solve, that Boost.Serialization also had to solve, but geared towards an unformatted data stream. Among them: - optional serialization: a serialize() function can always leave out fields or introduce new ones, so you can never be sure that your database schema is complete - "pointer tracking"/foreign keys: Serialization maps pointers to object IDs. for ORM pointers have to be mapped to table-specific foreign keys. as an intermediate solution you could use a serialization wrapper (see [3]) to provide the necessary info to the Archive when serializing a pointer. - dynamic types/polymorphic foreign keys: Serialization uses user-defined strings to refer to dynamic object types (see [4]), for ORM you'll have to come up with a solution to refer to database tables of the most-derived type. - containers/non-unique names in NVPs: serialize() functions are allowed to put out multiple name-value-pairs with the same name. e.g. std::vector creates an "item" NVP for each element. your ORM Archive has to detect that and map it to a M:N relation. There might be more. I've thought about this for a while because I'm the author of a proposed boost library for object persistence. No ORM though at this point, currently it dumps unformatted serialized data into the database backend. HPH a bit, I'd be interested in any solution you come up with. [1] http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/serialization.ht... [2] http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/wrappers.html#nv... [3] http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/wrappers.html [4] http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/special.html#exp...