Re: [boost] Boost.SQL, SOCI and beyond

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-10-09 06:12:14

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