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 06:17:19

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