[odb-users] Mapping a templated wrapper class

R. Cortland Tompkins cort.tompkins at ipconfigure.com
Sun Sep 8 23:05:22 EDT 2013


Hello,

I made a templated wrapper class to facilitate persisting
boost-serializable objects.  My wrapper class maintains the object and a
text archive serialization of the object, and has logic to track changes
and keep the two in sync.

I initially attempted to specialize value_traits for my templated wrapper,
but the callbacks for the id_long_string type in MSSQL scared me off. :)
 At this point I was trying to serialize/deserialize on-the-fly without
maintaining a text archive in my wrapper, and there did not appear to be an
obvious or non-trivial way to put serialization/deserialization hooks into
the get_image/set_image methods since the callbacks that effect the get/set
are invoked after those functions return.

Failing that, I made my wrapper change-tracking and moved the
serialization/deserialization logic into its accessors, then followed the
example of boost::optional<> in libodb-boost to create a wrapper_traits
specialization whose wrapped_type is always std::string (the text archive)
regardless of the template parameter.  This method seems cleaner than my
first attempt, but things get less tidy when I have to map to DB types.

I made a profile for my wrapper, with per-database option files to add
#pragma mapping headers to the appropriate prologues.  I was hoping I could
map my generic wrapper class to the various "TEXT" DB types (independent of
the template parameter as described above), but it seems this is not
possible.  As a work-around, I have typedef'd a template specialization for
each of the wrapped serializable class types I intend to use, and mapped
each of these separately in each mapping file.

This works but is obviously a bit fiddly.  Is there a way that would avoid
a priori enumeration in the mapping headers of all the serializable types I
use?  Revisiting my first attempt, would a value_traits specialized for my
templated wrapper class and the appropriate DB type eliminate the need for
#pragma type definitions?


Thanks,
Cort Tompkins


More information about the odb-users mailing list