Indeed. I'm facing similar issues. I've introduced ad-hoc introspection, but doing the reflection part right, in a typesafe manner, which plays nice with aggregate C++ types which expand into several SQL columns (with C++ to SQL type transformations in the middle), or which play nice with polymorphic foreign-keys (which can also expand to several columns if modeled using XARC), is currently out-of-reach for us, worked-around by lots of ad-hoc code again. The introspection part at least helps with SQL schema management and statement SQL text generation, but without reflection of lot must be spelled out in explicit code.

I'm aware of some high-voodoo template-based introspection libraries in the boost sandbox or announced on the list, but haven't used them, as they tend to be too "templat'y" to be accepted in my organization. I don't know if any actually provides reflection. Adding introspection and reflection as a library feature tend to yield complex and slow to compile code it seems, compared to what a language feature could provide, and almost always involves lots of macros too. But I'm getting off track here. Hopefully this thread can provides interesting nuggets of wisdom on this subject. --DD