Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?

Subject: Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-12-14 03:28:06

> >
> > - 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
> >
> 
> 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.
5. Support of both prepared and unprepared statements.

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.

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

First of all it is not GPL it is LGPL that is absolutly useable
in any propriatary closed source project. It just keeps incurages
users to release fixes they do.

IMHO LGPL is much closer to BSL then GPL and this is probably
what many developers should understand, and basically if you use
SOCI for example with MySQL then you should know that you use
GPL code, and when you develop almost any application under Linux
you do use LGPL/GPL code. So ingoring this fact is just ignoring
real world situation.

I would say that I'm going to release it under BSL
for being it part of Boost as it has significant advantage
to have library in Boost. But other then that I'd prefer
to keep it LGPL meanwhile.

Best
  Artyom