From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-12-05 17:25:28
Maciej Sobczak wrote:
> Beman Dawes wrote:
>> > 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.
> Which raises a series of new questions.
> Now, the SOCI library provides a common interface that is independent
> from the particular server technology (well, as far as SQL dialects
> go...). The user of the library can select any supported platform by
> naming the factory object at the connection time:
> Session sql(oracle, "some parameters");
> Above, oracle is a name of the factory singleton that is used by Session
> to create concrete instances for relevant backend objects.
> For the last three releases we have focused on getting as many working
> backends (which translate into many factories) as possible, which makes
> SOCI practically useful. The word "practically" is crucial here, because
> this is where the possible standardization process can get tricky. The
> standard was always very careful not to impose any constraints that
> would unnecessarily limit the implementation possibilities and this will
> have to be applied here as well. I understand that the committee will be
> reluctant to put any obligation that the implementation must provide
> this or that backend factory, which in reality will mean that vendors
> will be able to provide no factory at all, or just their favourite, so
> that there will be environments that don't have any single factory in
> common. Just for the sake of practical example: Microsoft will provide
> odbc and/or mssql factory, GNU people will provide mysql and postgresql
> and the portability of final applications is gone.
> In fact, I see three possibilities:
> 1. Define backend interface in a way that allows vendors to provide
> standard-compliant backends. From the interface point of view they will
> be replaceable, so that two vendors will be able to provide, let's say,
> the oracle factory, but that still means that the portability of final
> programs will be severely limited because of the strong dependency on
> the availability of any given factory in the target environment.
> 2. Define some "reasonable" set of backends (the current set in SOCI is
> reasonable) and oblige vendors to implement all of them. This is
> completely unrealistic for political reasons.
> 3. Decouple the low-level mechanics even further and state that the way
> to choose the backend is implementation-defined and external to the C++
> itself. This basically brings us to ODBC, which we might therefore
> standardize right now.
How about this:
4. Same as (1), but also require one generic backend, say
"default_backend", with a portable set of parameters that are really
just hints. Vendors could supply additional backends if they desired.
The details of default_backend are not otherwise specified.
The idea is that those who care more about portability than performance
can use default_backend, while those who want the attributes of some
specific backend can specify it. They then have to obtain an
implementation of that backend if they move to another platform.
> My point is that even though I really see SOCI as a very practical tool
> for people that need practical solutions, I don't see how it might get
> ever standardized. You just cannot standardize that the library has to
> support Oracle/MySQL/whatever and if you don't standardize it, there is
> very little left.
I'll defer commenting on that until I've studied the SOCI docs a bit.
Thanks for your interest in Boostifying SOCI!
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk