[boost] SOCI 3.0.0 - The Database Access Library

From: Maciej Sobczak (prog_at_[hidden])
Date: 2008-07-10 03:51:00

Hi,

After more than one year and a half from the last release I'm pleased to 
announce the availability of the next major SOCI release (3.0.0).

The SOCI library is a C++ database access library that during the last 
years was recognized for its innovative interface, ease of use and high 
quality. The main project website is:

http://soci.sourceforge.net/

The 3.0.0 release brings many improvements and new features. Some of 
them were suggested here during previous discussions on database 
interfaces. Some of them will be explained in more detail below.

The most important of the new library features include:

* Naming and coding convention compliant with Boost.

* Integration with Boost types: optional, tuple, fusion and gregorian::date.

Please see <http://soci.sourceforge.net/doc/boost.html> for details.

* Dynamic backend loading.

The advantages and potential uses of this feature have been discussed 
here previously.
An example code establishing the new connection to the database might 
look like:

soci::session sql("postgresql://dbname=my_database");

As a result, the SOCI library will try to locate the dynamically 
loadable plugin (called backend) for PostgreSQL and handle all further 
database-related activity.

This feature exists not instead, but in addition to the statically-bound 
interface that was available in previous releases.

* Multithreaded connection pool.

* Improved integration and conversion system for user-defined datatypes.

Actually, integration with Boost types has been implemented with the 
help of this conversion system. It is non-intrusive and based on traits, 
which means that neither SOCI nor user-defined types need to be modified 
to integrate them. This system is also composable, which means that 
user-defined datatypes can wrap one another without special 
arrangements. For example, boost::tuple can contain 
boost::optional<Employee> even though all three conversion traits can be 
defined separately.

* Extended the set of basic datatypes with long long.

* Additional simplified interface (of the extern "C" type) for 
integration with other programming languages.

It is expected that bindings for other languages will be created as 
external projects with the potential advantage of reducing the total 
number of libraries used in multi-language projects and increasing 
conceptual coherency of database-related operations.
Boost.Python and similar solutions can be helpful here.

The 3.0.0 release includes the following backends:

* Oracle
* PostgreSQL
* MySQL

They were tested on a variety of platforms, please see the documentation 
pages devoted to each backend for details.

Other backends (ODBC, SQLite, Firebird) exist in the CVS repository and 
are provided "as is" for those who are willing to experiment with them 
and accept the cost of using less-tested and unsupported code.
It is very likely that future releases of the library will officially 
include some of these additional backends. It is also possible that 
other database servers will be targeted with dedicated backends.

An extensive HTML documentation is available both on the project website 
and as part of the distribution. In particular, the doc/structure.html 
page explains the structure of the library and provides instructions how 
to build it.

------

This release is also a good motivation for reviving the discussion on 
the future Boost database library.
As you have seen during the last couple of years, SOCI is one of the 
very few (should I say "the only one"?) projects that actually move 
forward and that are now culturally consistent with Boost.
The extensive out-of-the-box integration with the Boost datatypes, Boost 
license and compliant naming conventions, already make SOCI the natural 
choice in those projects that use Boost libraries.
As a natural consequence of this, the following question has to be asked:

What is the future of database interfacing from the Boost community 
point of view?

Proposing SOCI as a candidate library for Boost might be a possible 
answer to this question, but it is not obvious in a wider perspective. 
Some of the SOCI users do not use Boost for various reasons and this 
justifies retaining SOCI as a separate entity (note: even though SOCI 
offers extensive integration with Boost, it does not mandate it and SOCI 
can be compiled without any reference to Boost). Most likely solution is 
to keep SOCI orbiting around Boost in terms of coding conventions and 
seamless interfacing, as it does today, so that benefits for all 
interested parties can be retained.

Your comments and suggestions considering the above are very welcome.

Final note: SOCI does not use bjam. If this is considered as missing 
from the Boost point of view, contributions from experienced bjam users 
would be needed.

Cheers,

-- 
Maciej Sobczak * www.msobczak.com * www.inspirel.com