Steve Hutton wrote:
On 2006-10-05, Nicola Musatti <Nicola.Musatti@gmail.com> wrote:
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
Steve Hutton <shutton <at> featurecomplete.com> writes: [...] 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.