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?
Almost every database around fully supports Unicode - sqlite3, postgresql, mysql and many others - they use UTF-8 as the text encoding without any problems. So as long as you keep working with UTF-8 you are on the right way, ODBC backend knows to convert UTF-8 to UTF-16 and backward for thous databases that do not support UTF-8 naively (i.e. MS SQL Server).
You're talking about SOCI 3 right?
I don't see how using the git version would be a problem though.
As long as you use it on your own and not have to recommend SQL library for customers. Also git-version tends to break once in a while.
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.
I didn't post the link to the tutorial for nothing :-) See: http://art-blog.no-ip.info/sql/cppdb/ http://art-blog.no-ip.info/sql/cppdb/intro.html http://art-blog.no-ip.info/sql/cppdb/stat.html http://art-blog.no-ip.info/sql/cppdb/query.html Also unlike SOCI it allows both verbose API and syntactic sugar: sql << "INSERT INTO foo values(?,?)" << x << y << exec; or statement st = sql.prepare("INSERT INTO foo values(?,?)"); st.bind(1,x); st.bind(2,y); st.exec(); Depending on what do you prefer.
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?
The primary advantage is using prepared statements caching that gives boost (depending on engine) of about 20% to 150% percents. But executing same queries in same way would give close performance to native client.
That said, I'd really not like to use code that is anywhere near the GPL in all my projects.
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.
LGPL does not prevent forking. It just requires provide your client on request the changes you did in your private fork. It is fine to bundle the DLL of your private fork in proprietary project as long as you can provide sources for this DLL you had changed and I think this is quite fair requirement. Many... Many proprietary projects do this.
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".
I agree this is simpler to deal with MIT, BSD (3 cluse), BSL code then with LGPL... but it is not as hard as many see this. There is just a big fobia of everithing connected to a stuff that includes 3 letters "GPL"
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/
Speaking of exceptions, BSL is not one of the licenses under MySQL foss-exeptions.
That said, others might (like me) not touch your code or even look at it because it's under the LGPL,
I would say - their loss. In any case, if it comes to Boost it would be BSL licensed. Regards, Artyom