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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-12-05 13:15:38

Nicola Musatti wrote:
> Maciej Sobczak <prog <at> msobczak.com> writes:
> [...]
>> I would like to stress that the ODBC support was our important milestone
>> that now allows us to claim a quite extensive coverage of existing 
>> database technologies. With this in mind, SOCI becomes even more serious 
>> and our roadmap for the nearest future is to bring the library to the 
>> state that will make it a valid candidate for inclusion into Boost. We 
>> will therefore welcome your guidance and suggestions w.r.t. Boost 
>> compliance.
>>
>> Note that up to this release, the library was deliberately developed 
>> without any external dependencies, so there are obviously wide areas 
>> where Boost might be applied within the library itself (example: 
>> intrusive pointers to manage some refcounted objects). This is easy.
>> The more difficult part is the library interface and its general philosophy.
> 
> The last time this topic was discussed, it was hoped that the outcome could be
> a proposal to be included in the standard committee's TR2. Even though that
> deadline has passed proposing a library for inclusion in the standard is
> certainly a worthwhile objective; is that something you want to pursue with
> SOCI?

As a long-time C++ committee member, I can say with certainty that the 
committee will be *very* interested in a Boost Database library. Please 
don't worry about whether it is for TR2, TR3, or something else. Just 
proceed with getting SOCI ready for a Boost formal review, and work on 
the assumption that if Boost users find the library useful, it will be 
proposed for eventual standardization.

 > I'm asking because I think that the answer may influence interface
 > choices, e.g. to simplify support for single backend implementations
 > or to limit use of Boost libraries to those accepted in the TR's.

For the public interface, I think it is appropriate to depend on any 
Boost library accepted for TR1,TR2, or C++0x. As far as the internal 
implementation goes, that is pretty much up to the library's 
implementors, IMO.

> As I already mentioned in a previous discussion I believe that a distinction
> should be introduced between core DB access functionality and higher
> abstractions such as the object/relational mapping, especially in view of a
> possible standard submission.

The C++ committee's LWG tends to prefer that a library expose the 
lower-level functionality used to build higher-level abstractions, 
particularly when the library is implemented by calls to third-party API's.

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.

--Beman