- 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 --------------- http://boost-spirit.com