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

Subject: Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-12-14 04:45:41

> 
> > 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