Re: [boost] SOCI 2.2.0 - The C++ Database Access Library

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-12-06 14:33:59

Nicola Musatti wrote:
>
 > ... You just need to provide access to your backends from textual
> keywords, possibly making it possible for vendors to default to their 
> preferred one when none is specified.

Yes, that is what I had in mind. If the textual name isn't supplied by 
the vendor, it is simply a error. Users can fallback to the vendor 
default, or obtain the missing backend from a third-party.

> SOCI may come to satisfy two very different needs: provide a well tested 
> end user interface for standardization *and* a practical, open source 
> solution for accessing your databases. The standard interface may not 
> mention specific backends, but commercial solutions will have to compete 
> with what SOCI offers free of charge. In a way, even if vendors were to 
> rip SOCI's implementation and call it their product it would be a success.

Yes.

> I don't think how backends are provided is really a concern from the 
> committee's point of view, even if it is of high practical importance.

Yes. I'm of the personal opinion that the committee should require that 
a default backend be provided, but which one isn't likely to specified 
in the standard.

> I 
> understand Beman's comment to mean that the committee prefers libraries 
> that are the thinnest layer above the underlying technology that 
> provides sufficient abstraction.

Yes.

 > In other words SOCI should not attempt
> to provide a complete object/relational mapping with all bells and whistles.

The committee might also like higher level functionality, perhaps even 
"a complete object/relational mapping with all bells and whistles," but 
that higher level functionality should be built on top of the lower 
level functionality. How this plays on for SOCI, I don't know yet.

>>> Speaking of third-parties, requiring the user to include headers 
>>> specific to particular back-ends sounds controversial, although I 
>>> haven't studied SOCO's interface yet so don't know that for sure.
>> You don't include third-party API. You only include the header that 
>> gives you visibility of the given factory.
>> In other words, in order to do this:
>>
>> Session sql(oracle, "some params");
>>
>> you need to #include "soci.h" (for Session and other independent stuff) 
>> and "soci-oracle.h" (so that you see oracle as the name of the singleton 
>> factory). 
> 
> As I said I think that even this can and should be done away with.

I'm also concerned, although I want to understand more before absolutely 
saying that the approach should be changed.

--Beman