Boost logo

Boost :

Subject: Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2010-12-14 09:53:15

> > > - Performance is the primary goal - make fastest possible SQL
> > > connectivity as possible
> > > - Transparent connection pooling support
> > > - Transparent prepared statements caching
> > > - Dynamic DB modules loading and optional static linking
> > > - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL,
> > > Sqlite3
> > > - Support as many RDBMSs as possible via cppdb-odbc bridge
> > > - Simplicity in use
> > > - Locale safety
> > > - Support of both explicit verbose API and brief and nice
> > > syntactic sugar

I'm interested.

> > How is this different from SOCI and why should I use CppDB over SOCI?
> Before I answer this question I'll tell that I'm familiar with SOCI, I
> used it for a while and I even had submitted several patches (for example
> dynamic backend loading
> implementation) to SOCI so I had reasons to implement something different
> then SOCI.
> Lets start from clear advantages:
> 1. Transparent prepared statements caching - it gives with 0
> effort significant performance boost.
> 2. Transparent use of connection pooling (only you need to add
> an option in connection string).
> 3. Full support of Sqlite3 and MySQL (SOCI's implementation of them
> is very poor)
> 4. Unicode Support in ODBC, i.e. you can use Unicode with MS
> SQL Server that does know speaks in UTF-8, SOCI does not
> support this.

Is that Unicode support integrated or do you rely on a separate Unicode
library? If it came to a Boost submission, I believe separating this from
your library would be a prerogative.

> 5. Support of both prepared and unprepared statements.

Sounds promising, indeed.

> Few additional and less obvious points :
> 1. When last SOCI version was released? 2 Years ago, non-GIT soci
> version has lots of bugs and issues. So basically you need to
> use git version to use up-to-date SOCI.
> 2. SOCI was originally created as OCI wrapper and has some
> "Oracle quircks" - but this is a metter of tase.
> Don't get me wrong, I like SOCI but I still think that my library provides
> some important added values that SOCI does not.

SOCI is non-GPL, so this is a clear advantage.

> > That said, I'd really not like to use code that is anywhere near the
> > GPL in all my projects. If releasing under the Boost license is an
> > option for you, I think that would be the single thing that I would
> > expect for anything being submitted for review to Boost.
> >
> > [...]
> >
> > If I'm interested is another question, and the answer to that would
> > be: if you can show that your library is better than SOCI, then I
> > might be interested in using it -- but I'm not touching code that is
> > anywhere near the LGPL or the GPL for that matter if I can help it.

I second this. GPL'ed code is viral and I'm afraid to get infected :-P

Regards Hartmut

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