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

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2006-10-05 22:18:54

Nicola Musatti wrote:
> 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 .

Yes, I know these documents and I've already started to analyze SOCI
according these docs.

>> 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. 

Thank you!
This is what I've expected to hear. I absolutely agree and I'm sure our
understanding of boostification is very similar.
I also understand what you mean as "the suitability of some of the
interface choices made by the SOCI developers."
Personally, I can't talk for the whole SOCI team, I'd like to follow all
Boost guidelines and conventions, regarding naming, project layout, etc.

Initially, I misunderstood you a little having an impression there are
some conventions SOCI actually breaks regarding operator overloading or
using get(index) instead of operator[], etc.

Thanks again for clarification.

> 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. 

Yes. AFAIK, Boost gives developers some liberty in this subject.

>>>> 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.

Yes, I think I've been convinced :-)
I'm sure we will discuss in SOCI team all concepts proposed here.

> 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>()

Hmm, it's very interesting point, again.
Yes, I agree, these subtle differences can make a difference.
I'm inclined to discuss about incorporating it to SOCI.

Thank you for your valuable comments!

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net