Boost logo

Boost :

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


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:

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

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.


Maciej Sobczak * *

Boost list run by bdawes at, gregod at, cpdaniel at, john at