- 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