On Tue, Dec 14, 2010 at 3:18 PM, Artyom <artyomtnk@yahoo.com> wrote:
- 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?
Boost Interest --------------
Currently I'm think whether should I boostify it, release it under BSL (currently it is LGPLv3) and submit it for formal review in boost or shouldn't I?
Why do I ask, not because I'm thinking it is not good enough but rather because I feel that the "boostification" effort would be wasted at this point.
For about half a year ago I had submitted a Boost.Locale for formal review, I use it under other namespace as part of CppCMS project all the time and in fact I receive most request and bug reports for Boost.Locale via CppCMS project and not via CppCMS.Locale so basically I have to handle two projects and synchronize between them all the time, and Boost.Locale is still stuck in review queue.
So does it worth the effort?
So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily).
I'd say, it would be good to have a Generic Storage library that abstracts the details of whether it's being saved to a file, to a database, or to some other service in Boost. This way generic algorithms that deal with stored objects/data can be implemented and have "containers" or "silo's". Also, this way, anybody can adapt their storage client libraries to this Generic Storage API (if it's ever invented or agreed upon). 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. As for me, I'm not really satisfied with having to deal with niche libraries being made part of Boost (i.e. in this case the niche is database access) when there's a much more generic problem that needs solving (specifically, the abstraction of storage). 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. Thanks and I hope this helps. -- Dean Michael Berris deanberris.com