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

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!

--Beman