Re: [Boost-users] Boost-enabled loosely coupled ORM serialization

Subject: Re: [Boost-users] Boost-enabled loosely coupled ORM serialization
From: Stefan Strasser (strasser_at_[hidden])
Date: 2013-04-05 09:14:42

Zitat von Michael Powell <mwpowellhtx_at_[hidden]>:
> 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.html
[2]  
http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/wrappers.html#nvp
[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#export