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

From: Edward Diener (eldiener_at_[hidden])
Date: 2006-10-06 09:51:18

Steve Hutton wrote:
> 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.

Boost::optional is a way of representing a single alternative "value" to 
the domain of values for a particular type, which generally says "no 
value". It is not a way of representing all of the possible results of 
trying to obtain a value.

In your SOCI example above it appears that you are mixing, into your 
SOCI indicators, two different concepts. One, the "eNull" is a valid 
database null value, while the others, such as "eOK" and "eTruncated", 
are indications of the possible results of trying to obtain a value.

This is not saying that what you are designing is wrong, but just that 
the normal way of obtaining a value from a database table row's column 
is to return a variable indicating the value, of which a database null 
is a possible valid result, and offering some separate mechanism for 
determining if an error has occurred in obtaining a value, which is 
often an exception which is thrown or a separate error indicator which 
can be checked. In this scenario using boost::optional to return the 
value, while providing your SOCI indicators to check on any error which 
has occurred, may be a cleaner way to obtain a value, from the end 
user's perspective, than what you have designed.