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
>> 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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk