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

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

Steve Hutton <shutton <at> featurecomplete.com> writes:
[...]
> 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.

I believe this is an instance of the need of representing concepts both in the
SQL and in the C++ world. I see indicators as conceptually a part of the SQL
world, in that they are a way to access additional, detailed information about
the result of a query, beyond the retrieved value itself.

Once the value is converted to a C++ type it assumes a value in the domain of
that type... or not. In this case boost::optional or its moral equivalent is a
reasonable representation.

Side note: a while ago I wrote a Nullable<T> type that provided implicit
conversion to T and threw an exception if it held a null value. Personally I'd
prefer that kind of interface, but I think it's better to stick as much as
possible to what's available in the standard library or in Boost.

> 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.

I suspect there's some misunderstanding. By writing '.as<T>' I didn't mean to
imply that retrieved field values should be converted to arbitrary types. I just
feel, and I'm convinced that it's the same for you, that whenever it is possible
it is better to write 'get<int>' than 'get_int'. I used 'as' to express value
retrieval because it is used in libraries I'm familiar with.

The only conversion that might be reasonable is towards string/wstring, in case
the underlying technology provides an efficient implementation (e.g. because it
retrieves values as strings and only converts them upon request).

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

I did read it. I know that your choices were thought out in full, but I still
disagree about a few things :-)

Cheers,
Nicola Musatti