Jeff Garland <jeff <at> crystalclearsoftware.com> writes: [...]
Now there's an infinite number of solutions to the mapping problem. Many approaches maintain the member/mapping information outside of the code in configuration. That's fine, but personally, I usually prefer to have a way to maintain this information directly in the code -- the main reason being that most of the changes above require modification of the code. So when I make any of these modifications, ideally I want to go to one file, make the change, recompile, update the schema if needed, and move on. If there's another file, that's a non-local change that someone has to go find and make.
There are two places where that information needs to be represented: in the database schema and, possibly implicitly, in the part of the application logic that uses that information. The only way I see not to have to maintain a third set of information, i.e. the explicit connection between db schema and C++ data types is to generate it automatically. [Example of the current SOCI O/R mapping and an hypothetical alternative mapping registry snipped]
No obviously this loses the ability to write a function to do field specific conversions. This might be overcome by making the registry information more sophisticated. It still suffers from requiring 2 updates for several of the scenarios, but they are local. A more sophisticated approach could actually build the base_query.
The problem I see is that while you may achieve locality of information, the number of information items you may need to store for each field/attribute mapping still makes maintenance by hand inconvenient as soon as your db schema grows beyond a handful of tables.
It's an interesting idea (might require full SQL parser to achieve?)
I think this is overkill.
This depends on the complexity of the application, but the parsing infrastructure doesn't take much longer than a day or two with a dynamic language and a parser generator, than writing the generating function for every type of code item you may want to generate won't take much longer than writing, say, three or four such items by hand. From the fifth table onward it's all gains. Cheers, Nicola Musatti