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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk