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

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

Mateusz Loskot <mateusz <at> loskot.net> writes:
> Nicola Musatti wrote:
[...]
> Could you elaborate what you consider as boostable or boostified
> intefrace/library?
> May be you could point a document where I can find general
> guidelines about Boost conforming library interface design?

The most reasonable starting point is: http://boost.org/more/lib_guide.htm .

> I noticed you're using these terms like "boostified version of SOCI"
> or "suitability of some of the interface choices" or
> "with Boost compliance in mind" but I have no idea how to understand them.
> 
> Understanding of these terms may be crucial to identify if SOCI
> is or isn't compliant with Boost library interface design
> guidelines, etc.
> 
> I believe, it's not only a matter of taste, is it?

In part. Coding and naming conventions, library organization and directory
structure are objective issues which are documented in the page I linked above
or elsewhere in the Boost web site and other details may be gathered from how
existing Boost libraries are organized, especially the most recent ones. 

On the other hand defining what consititutes a suitable interface for a Boost or
a standard library has to do with personal expectations and experience, and can
only be subject to consensus among interested developers. 

> >> Row r;
> >> sql << "select * from ex2", into(r);
> >>
> >>>              // Columns may be accessed by position...
> >>>              std::cout << r[0].as<long>() << "\t ";
> >>
> >> SOCI equivalent: r.get<long>(0)
> > 
> > I consider this a small abstraction mismatch: you apply the index to the
> > row and then you convert the field value to a C++ type. By the way, in
> > this case operator[] is the natural way to express indexing, so I believe
> > that operator overloading should be preferred.
> 
> I agree, only and only if elements of a sequence can be
> identified only by index.
> In SOCI, when working with Row representation the situation is
> different - elements of Row can accessed *also* via name,
> what's natural in DBMS, where columns are named.
> So, SOCI interface is consistent and intuitive in this case:
> 
> r.get<long>(0)
> r.get<long>("column1)
> 
> See:
> http://soci.sourceforge.net/doc/reference.html#row

I do not agree. The use of square brackets with non integer arguments is common
when speaking of associative maps and is present in the standard library in
std::map's interface.

Moreover, I was pointing out another issue: when you have a row you first index
it to get a field and then you translate its value to your destination. What I
wrote as 

r[0].as<long>()

could be expressed in a more SOCI-like syntax as

r.field(0).get<long>()

Cheers,
Nicola Musatti