From: Dr. Franz Fehringer (fehrin_at_[hidden])
Date: 2008-07-11 02:38:20
I have two questions:
1) Does SOCI support IBM DB2 in general?
2) same but for z/OS?
Thanks for the great work
Maciej Sobczak schrieb:
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk