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

From: Maciej Sobczak (prog_at_[hidden])
Date: 2006-12-05 16:29:30

Hi,

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.

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.

> 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.

This is to a large extent how SOCI works. The backend interface is 
specified and documented and we were very successful with this - people 
just jumped in to the project with ready backends that complied with the 
interface. Most of the time, of course, the authors of new backends have 
borrowed from existing backends, but it's in principle not necessary.

> 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). This is no different than for example:

#include "iolibrary.h"
#include "sockets.h"

where sockets is just one possible factory for use with iolibrary, or this:

#include "gui.h"
#include "silverbuttons.h"

and so on.
There should be nothing controversial with this approach.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/