On Tue, Dec 14, 2010 at 5:45 PM, Artyom <artyomtnk@yahoo.com> wrote:
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).
Yes, but more specifically I should have asked, does your library natively support wide strings (std::wstring) and handle the conversion from std::wstring to the appropriate UTF-8 encoding in narrow strings API's or the native multi-byte string APIs of the libraries?
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.
Sure, much like how Boost breaks even in regular releases. ;)
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 :-)
Ha! I missed that part, thought the links were just for reference documentation, was too lazy to look at the information there. ;)
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.
Cool. :)
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 that's dependent on the type of the query and the backend. Have you measured just the overhead/difference of just CppDB?
But executing same queries in same way would give close performance to native client.
Okay, I can believe that.
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.
Yes, but not all my clients want to have to release changes they make to the libraries they use. This is where more permissive licenses make sense -- and this is the same reason why the BSL is actually better in most respects for libraries than the LGPL.
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.
It actually is as hard as it sounds. <rant> First, I cannot make changes to the library that I don't want to share. There may be a lot of reasons for this for example, if I've developed my proprietary system and proprietary protocol for DB access. In this case I cannot write a backend that talks with my proprietary system because the LGPL requires me to release these changes when I distribute them in my software. That's a non-starter for proprietary software developers. Second, the politics of LGPL are just incompatible with proprietary extensions. Imagine if someone was developing a device and wanted to create proprietary extensions to that underlying system and not have to release the source to these proprietary extensions -- and a C++ runtime on top of it. Because libstdc++ is under the GPL, this means the changes to the sources would have to be made public. Even if you had an LGPL-licensed standard library you're *forced* to release changes when you distribute the binaries. This kind of politics is what is deterring proprietary software developers and consultants from recommending and supporting the GPL and the LGPL. This is also why people are working on other (better?) implementations of the standard library and compilers that don't have this viral license. </rant> There are a ton more reasons why the dogmatic view that all software should be Free as in Speech doesn't work well in business -- and in the business of software, there's usually more than one way to do things. I don't see a compelling reason then to have to sacrifice the principle of tolerance and neutrality if I have other choices for database client libraries than one that is under the GPL/LGPL. :)
There is just a big fobia of everithing connected to a stuff that includes 3 letters "GPL"
For good reason. For a case study on why, read up on the case that LinkSys ran into when they embedded Linux in their WRT routers. Also, there's the issue with why MySQL's development model was a bad idea; that having all copyright assigned to just one person/entity lends itself to abuse.
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.
Okay, so that means the Open Source MySQL client libraries is a non-starter for non-GPL code. That sucks.
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.
It's the other way around -- the less users who'll use your library, it's your loss. Also, if you want it in Boost, it would have to be released under the BSL. :) -- Dean Michael Berris deanberris.com