On Tue, Dec 14, 2010 at 4:28 PM, Artyom <artyomtnk@yahoo.com> wrote:
How is this different from SOCI and why should I use CppDB over SOCI?
[snip]
Lets start from clear advantages:
1. Transparent prepared statements caching - it gives with 0 effort significant performance boost.
Okay.
2. Transparent use of connection pooling (only you need to add an option in connection string).
Cool.
3. Full support of Sqlite3 and MySQL (SOCI's implementation of them is very poor)
Alright, that's good.
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.
Right. So how do you support Unicode that's not going through ODBC?
5. Support of both prepared and unprepared statements.
That sounds good.
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.
You're talking about SOCI 3 right? I don't see how using the git version would be a problem though.
2. SOCI was originally created as OCI wrapper and has some "Oracle quircks" - but this is a metter of tase.
Yeah, but... the quirks aren't really that bad.
Don't get me wrong, I like SOCI but I still think that my library provides some important added values that SOCI does not.
Sure, but how does your interface look like? The good thing with SOCI is that the interface is nice and easy to deal with. Sure it has some issues with some underlying details, but largely since you're dealing with database access, it's easy to see that the bottleneck is typically not the library accessing the DB. That said though, if your implementation is really much faster than implementations that use SOCI, then that would be a compelling difference. Have you measured the effect of CppDB over SOCI -- for example, did you try retrieving a record of 1000 rows and measured the positive effect that CppDB brings over SOCI?
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.
LGPL means I cannot do a private fork if I'm offering a service to clients and/or enhancing it in case I bundle it with my product. The reason people still stay away from LGPL is precisely because of these two issues I bring up. This is also the reason why permissive licenses like MIT, BSD, and similar licenses are more "commercial friendly".
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.
Yes, which is why commercial products either have to pay MySQL AB (now Oracle) for a license to use MySQL that's released under a non-GPL license. At least people have that option. In case you're working on FOSS -- which SOCI is -- you're exempt from the GPLv2 virus. [0] Also, Linux has a binary linkage exception on the system calls, and so does libstdc++, glibc, and all the base libraries that come with Linux. That's different from developing a library that's meant to be open source. Of course it is your library, and if you don't want to release it under the BSL at this time, then I don't see why you should. [0] http://www.mysql.com/about/legal/licensing/foss-exception/
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.
Sure, but I think one of the requirements for review would be that the code is under the BSL. So the real reason is, do you want to submit it to Boost in case others (like me) want to see your library in Boost. That said, others might (like me) not touch your code or even look at it because it's under the LGPL, so it's really going to be up to you. ;) -- Dean Michael Berris deanberris.com