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

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-12-05 17:33:15

Maciej Sobczak wrote:
> Beman Dawes wrote:
[...]
>> 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.

Why should that be? Just as you should have gotten (but did not) Oracle 
SQL CLI, DB2 SQL CLI, etc., all compliant with the ISO - X/Open SQL CLI 
standard, you should now get Oracle SOCI and DB2 SOCI each with their 
own backend, and possibly Boost.SOCI providing both and more. The 
important thing is to get the same C++ API from all of them.

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

I expect a standard proposal not to impose any kind of constraint on how 
backends should be provided. The important thing is that the end user 
API is standardized.

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

Actually ODBC is about the only database access library that happens to 
be based on a standard... More seriously, it doesn't have to go that 
far. You just need to provide access to your backends from textual 
keywords, possibly making it possible for vendors to default to their 
preferred one when none is specified.

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

SOCI may come to satisfy two very different needs: provide a well tested 
end user interface for standardization *and* a practical, open source 
solution for accessing your databases. The standard interface may not 
mention specific backends, but commercial solutions will have to compete 
with what SOCI offers free of charge. In a way, even if vendors were to 
rip SOCI's implementation and call it their product it would be a success.

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

I don't think how backends are provided is really a concern from the 
committee's point of view, even if it is of high practical importance. I 
understand Beman's comment to mean that the committee prefers libraries 
that are the thinnest layer above the underlying technology that 
provides sufficient abstraction. In other words SOCI should not attempt 
to provide a complete object/relational mapping with all bells and whistles.

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

As I said I think that even this can and should be done away with.

Cheers,
Nicola Musatti