[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