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

From: Steve Hutton (shutton_at_[hidden])
Date: 2006-10-06 02:23:51

On 2006-10-05, Nicola Musatti <Nicola.Musatti_at_[hidden]> wrote:
> Steve Hutton <shutton <at> featurecomplete.com> writes:
> [...]
>> Ok, I'll reply below with the SOCI equivalent of your example code,
>> mainly because I don't think it differs too much in substance.
>
> Yes. I believe that the key abstractions have been identified once and for all,
> to the point that many libraries in this area share a common design. However, as
> in the long run the objective is to propose a standard interface the details of
> the API become important.

Maciej has limited net access right now, so he requested this be posted
on his behalf:

1. Considering the use of boost::optional - it's is indeed the very
elegant way to deal with NULL values, but SOCI indicators can provide
more information than this.  The indicator is a general information 
about the piece of data, which in addition to be eOK or eNull, might
be also eTruncated (when the string is read into the buffer that is too
short). boost::optional cannot do this and therefore cannot be the only
interface. It might be provided as an additional interface for the most
typical case (nobody's using char[] buffers anyway), but it cannot replace
indicators.

2. Considering the indexing of Row (function-like vs. operator[]) - the
syntactic sugar is a matter of taste, but I have nothing against, say,
r[0].get<int>() (this is easy to do). Things like 'as<T>' are not so 
convincing, especially when compared with the existing interfaces, 
like boost::tuple.

3. For rationale on the interface choices (like operator overloading),
please see
http://soci.sourceforge.net/doc/rationale.html

4. Yes, we were waiting for ODBC support. It was clear from the very
beginning that for the DB library to get any wider acceptance  it must
provide *some* support for MS servers.

Maciej Sobczak