On 2006-10-05, Nicola Musatti <Nicola.Musatti@gmail.com> 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