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

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2006-12-05 17:03:42

Maciej Sobczak wrote:

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

FWIW: POSIX has been standardized without any mentioning, how the backend
should be implemented (which file system to use etc.), STL has been
standardized without any mentioning, how to implement a std::map etc. 

I think you should use a similar approach, just standardize the interface
and leave the backend implementation to the vendor (what's possible, though,
is to specify the interface to the backend as well, just to make these
interchangeable).

Portability of a application should not be compromized in this scenario,
because your application runs without changes on any platform supporting the
standarized API not caring about the used backend. In the end you don't care
about the used filesystem as well...

Regards Hartmut