Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net