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