Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?

Subject: Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-14 03:59:36

On Tue, Dec 14, 2010 at 4:28 PM, Artyom <artyomtnk_at_[hidden]> 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