[SQL-Connectivity] Is Boost interested in CppDB?

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[SQL-Connectivity] Is Boost interested in CppDB?

Artyom Beilis
Hello,

I have recently released a new SQL Connectivity library:

General
-------

Documentation  : http://art-blog.no-ip.info/sql/cppdb/
Mirror Docs.   : http://cppcms.sourceforge.net/sql/cppdb/
Download        : https://sourceforge.net/projects/cppcms/files/cppdb/


Features
--------

- Performance is the primary goal - make fastest possible
  SQL connectivity as possible
- Transparent connection pooling support
- Transparent prepared statements caching
- Dynamic DB modules loading and optional static linking
- Full and high priority support of FOSS RDBMS: MySQL,
  PostgreSQL, Sqlite3
- Support as many  RDBMSs as possible via cppdb-odbc bridge
- Simplicity in use
- Locale safety
- Support of both explicit verbose API and brief
  and nice syntactic sugar

What it is not:
---------------
This is not ORM library and not supposed to be so.

This is something similar to what JDBC gives to JDK and QtSql gives
to Qt and more.


Boost Interest
--------------

Currently I'm think whether should I boostify it,
release it under BSL (currently it is LGPLv3) and
submit it for formal review in boost or shouldn't I?

Why do I ask, not because I'm thinking it is not good enough
but rather because I feel that the "boostification" effort
would be wasted at this point.

For about half a year ago I had submitted a Boost.Locale for formal
review, I use it under other namespace as part of CppCMS project all the
time and in fact I receive most request and bug reports for Boost.Locale via
CppCMS project and not via CppCMS.Locale so basically I have
to handle two projects and synchronize between them all the time,
and Boost.Locale is still stuck in review queue.

So does it worth the effort?

So before I do any steps forward may be it is better to
make sure it gets (or even passes the review) and then
boostify the library (which can be done very easily).

Regards,
  Artyom


     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Dean Michael Berris
On Tue, Dec 14, 2010 at 3:18 PM, Artyom <[hidden email]> wrote:

>
> - Performance is the primary goal - make fastest possible
>  SQL connectivity as possible
> - Transparent connection pooling support
> - Transparent prepared statements caching
> - Dynamic DB modules loading and optional static linking
> - Full and high priority support of FOSS RDBMS: MySQL,
>  PostgreSQL, Sqlite3
> - Support as many  RDBMSs as possible via cppdb-odbc bridge
> - Simplicity in use
> - Locale safety
> - Support of both explicit verbose API and brief
>  and nice syntactic sugar
>

How is this different from SOCI and why should I use CppDB over SOCI?

>
> Boost Interest
> --------------
>
> Currently I'm think whether should I boostify it,
> release it under BSL (currently it is LGPLv3) and
> submit it for formal review in boost or shouldn't I?
>
> Why do I ask, not because I'm thinking it is not good enough
> but rather because I feel that the "boostification" effort
> would be wasted at this point.
>
> For about half a year ago I had submitted a Boost.Locale for formal
> review, I use it under other namespace as part of CppCMS project all the
> time and in fact I receive most request and bug reports for Boost.Locale via
> CppCMS project and not via CppCMS.Locale so basically I have
> to handle two projects and synchronize between them all the time,
> and Boost.Locale is still stuck in review queue.
>
> So does it worth the effort?
>
> So before I do any steps forward may be it is better to
> make sure it gets (or even passes the review) and then
> boostify the library (which can be done very easily).
>

I'd say, it would be good to have a Generic Storage library that
abstracts the details of whether it's being saved to a file, to a
database, or to some other service in Boost. This way generic
algorithms that deal with stored objects/data can be implemented and
have "containers" or "silo's". Also, this way, anybody can adapt their
storage client libraries to this Generic Storage API (if it's ever
invented or agreed upon).

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. As for me,
I'm not really satisfied with having to deal with niche libraries
being made part of Boost (i.e. in this case the niche is database
access) when there's a much more generic problem that needs solving
(specifically, the abstraction of storage).

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.

Thanks and I hope this helps.

--
Dean Michael Berris
deanberris.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Artyom Beilis
> >
> > - Performance is the primary goal - make fastest  possible
> >  SQL connectivity as possible
> > - Transparent connection  pooling support
> > - Transparent prepared statements caching
> > -  Dynamic DB modules loading and optional static linking
> > - Full and high  priority support of FOSS RDBMS: MySQL,
> >  PostgreSQL, Sqlite3
> > -  Support as many  RDBMSs as possible via cppdb-odbc bridge
> > - Simplicity  in use
> > - Locale safety
> > - Support of both explicit verbose API  and brief
> >  and nice syntactic sugar
> >
>
> How is this different  from SOCI and why should I use CppDB over SOCI?
>

Before I answer this question I'll tell that I'm familiar
with SOCI, I used it for a while and I even had submitted
several patches (for example dynamic backend loading
implementation) to SOCI so I had reasons to implement
something different then SOCI.

Lets start from clear advantages:

1. Transparent prepared statements caching - it gives with 0
   effort significant performance boost.
2. Transparent use of connection pooling (only you need to add
   an option in connection string).
3. Full support of Sqlite3 and MySQL (SOCI's implementation of them
   is very poor)
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.
5. Support of both prepared and unprepared statements.

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.
2. SOCI was originally created as OCI wrapper and has some
   "Oracle quircks" - but this is a metter of tase.

Don't get me wrong, I like SOCI but I still think that my library
provides some important added values that SOCI does not.

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

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.

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.

Best
  Artyom


     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Dean Michael Berris
On Tue, Dec 14, 2010 at 4:28 PM, Artyom <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

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



     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Sylvain Pointeau
Hi,

I was starting a similar project, but focused only on sqlite3.
I was really missing that support in SOCI, that I would have loved to use.

I saw your APIs and it seems cleaner than SOCI and it is actually the way I
wanted to do my own lib, having a separated statement and results seems
cleaner in a long term.

However I think you are missing the boost integration (tuple, optional...)
that SOCI has.
Furthermore, I would recommend to use a already existing atomic int or ref
counted implementation in boost.

I also would like such a lib under the Boost license, because I want it to
be statically linked to my project and the LGPL is preventing it.

Best regards,
Sylvain
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Barend Gehrels-3
In reply to this post by Artyom Beilis


> So does it worth the effort?
>
> So before I do any steps forward may be it is better to
> make sure it gets (or even passes the review) and then
> boostify the library (which can be done very easily).

I'm interested in it.

Is the ODBC-bridge already working?

Regards, Barend


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Maciej Sobczak
In reply to this post by Artyom Beilis
Hi,

On 14/12/2010 10:45, Artyom wrote:

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

Please note that your argument about release schedule of the SOCI
library is very transient by nature. It will become out of date with the
next release of SOCI (whenever it happens).

>> Sure,  but how does your interface look like? The good thing with SOCI
>> is that the  interface is nice and easy to deal with.

> Also unlike SOCI it allows both verbose API and syntactic sugar:

SOCI does support several interfacing styles:

http://soci.sourceforge.net/doc/interfaces.html

> Depending on what do you prefer.

> There is just a big fobia of everithing connected to a stuff that includes
> 3 letters "GPL"

Yes. But you have to address it and if you try to do it by "educating"
everybody on this matter, then you will only alienate yourself.
You have to bend to user expectations. Bending user expectations to fit
your product is possible only if the product has no competition in its
niche, which is not the case here.

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

You still have to prove it. :-)

> In any case, if it comes to Boost it would be BSL licensed.

You got it backwards. It must be BSL to attract attention on this list,
not the other way round.

Cheers,

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Artyom Beilis
In reply to this post by Barend Gehrels-3
>
>
> > So does it worth the effort?
> >
> > So before I do any  steps forward may be it is better to
> > make sure it gets (or even passes  the review) and then
> > boostify the library (which can be done very  easily).
>
> I'm interested in it.
>
> Is the ODBC-bridge already  working?
>

Yes of course, read this:

   http://art-blog.no-ip.info/sql/cppdb/support.html

And this:

  http://art-blog.no-ip.info/sql/cppdb/odbc.html

Artyom


     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Emre Turkay-5
In reply to this post by Artyom Beilis
>
> 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.
>

I wonder if you can legally do that, I mean changing the license of some LGPL code to Boost?

emre


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Dean Michael Berris
In reply to this post by Artyom Beilis
On Tue, Dec 14, 2010 at 5:45 PM, Artyom <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Dean Michael Berris
In reply to this post by Emre Turkay-5
On Tue, Dec 14, 2010 at 6:45 PM, Emre Türkay <[hidden email]> wrote:
>>
>> 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.
>>
>
> I wonder if you can legally do that, I mean changing the license of some LGPL code to Boost?
>

IANAL, but, last time I checked, if you own the copyright, you can
release it under any license you want. ;)

--
Dean Michael Berris
deanberris.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Artyom Beilis
In reply to this post by Dean Michael Berris
> >> > 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?

No, as you don't need "wide" strings to use Unicode and actually wide
strings are not native ones for almost every database.

So for working with Unicode in CppDB you should use UTF-8.

Artyom


     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Artyom Beilis
In reply to this post by Maciej Sobczak
>
> > Also unlike SOCI it allows both verbose API and syntactic  sugar:
>
> SOCI does support several interfacing  styles:
>
> http://soci.sourceforge.net/doc/interfaces.html
>

Sorry, you are right, missed this somehow.

Thanks for correction,
  Artyom


     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Dean Michael Berris
In reply to this post by Artyom Beilis
On Tue, Dec 14, 2010 at 7:58 PM, Artyom <[hidden email]> wrote:
>>
>> 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?
>
> No, as you don't need "wide" strings to use Unicode and actually wide
> strings are not native ones for almost every database.
>

Okay. So that means people using std::wstring have to deal with
converting to UTF-8 encoded std::string on their own. Sounds like a
pain in Windows defaulted to use std::wstring in applications. :/

> So for working with Unicode in CppDB you should use UTF-8.
>

OK

--
Dean Michael Berris
deanberris.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Barend Gehrels-3
In reply to this post by Artyom Beilis
Hi Artyom,


On 14-12-2010 8:18, Artyom wrote:

> Hello,
>
> I have recently released a new SQL Connectivity library:
>
> General
> -------
>
> Documentation  : http://art-blog.no-ip.info/sql/cppdb/
> Mirror Docs.   : http://cppcms.sourceforge.net/sql/cppdb/
> Download        : https://sourceforge.net/projects/cppcms/files/cppdb/

The download seems pointing to another distribution (dbixx-0.0.4.tar.gz
containing 3 cpp files and not compiling) then the build instructions on
the doc, this is confusing me. I see the odbc now.

Regards, Barend




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Edward Diener-3
In reply to this post by Dean Michael Berris
On 12/14/2010 7:07 AM, Dean Michael Berris wrote:

> On Tue, Dec 14, 2010 at 7:58 PM, Artyom<[hidden email]>  wrote:
>>>
>>> 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?
>>
>> No, as you don't need "wide" strings to use Unicode and actually wide
>> strings are not native ones for almost every database.
>>
>
> Okay. So that means people using std::wstring have to deal with
> converting to UTF-8 encoded std::string on their own. Sounds like a
> pain in Windows defaulted to use std::wstring in applications. :/
>

Converting between Unicode encodings should be a separate library
anyway. Was there not someone working on such a cross-platform library
for Boost ? What happened to it ? Was it scrapped because of possible
Unicode support in C++0x ?

I apologize for taking this thread off-topic but I think that any
library using a particular Unicode encoding for its strings should be
exempt from the criticism that it does not have functionality dealing
with converting between Unicode encodings.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Artyom Beilis
In reply to this post by Barend Gehrels-3
> >  Documentation  : http://art-blog.no-ip.info/sql/cppdb/
> > Mirror  Docs.   : http://cppcms.sourceforge.net/sql/cppdb/
> > Download         : https://sourceforge.net/projects/cppcms/files/cppdb/
>
> The download  seems pointing to another distribution (dbixx-0.0.4.tar.gz
> containing 3 cpp  files and not compiling) then the build instructions on
> the doc, this is  confusing me. I see the odbc now.
>
> Regards,  Barend

You are trying to download the wrong file.

Under CppCMS project there are much more then one file, dbixx is just another
recently upladed file.

Go to cppdb -> 0.0.1  and download cppdb-0.0.1.tar.bz2 right at the link I have
you.

Full link is

   
http://sourceforge.net/projects/cppcms/files/cppdb/0.0.1/cppdb-0.0.1.tar.bz2/download


Artyom
>


     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Klaim - Joël Lamotte
In reply to this post by Edward Diener-3
Artyom, that posted the CppDB library is also the author of boost::locale
that is one of the libraries targeted to be proposed to boost to manage
Unicode and relaetd subjects. UTFCPP was also proposed to boost some time
ago.  boost::locale is more about locale and localization system while
UTFCPP is only about convertions between different UTF versions,using
std::base_string strings.

On Tue, Dec 14, 2010 at 14:45, Edward Diener <[hidden email]>wrote:

> On 12/14/2010 7:07 AM, Dean Michael Berris wrote:
>
>> On Tue, Dec 14, 2010 at 7:58 PM, Artyom<[hidden email]>  wrote:
>>
>>>
>>>> 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?
>>>>
>>>
>>> No, as you don't need "wide" strings to use Unicode and actually wide
>>> strings are not native ones for almost every database.
>>>
>>>
>> Okay. So that means people using std::wstring have to deal with
>> converting to UTF-8 encoded std::string on their own. Sounds like a
>> pain in Windows defaulted to use std::wstring in applications. :/
>>
>>
> Converting between Unicode encodings should be a separate library anyway.
> Was there not someone working on such a cross-platform library for Boost ?
> What happened to it ? Was it scrapped because of possible Unicode support in
> C++0x ?
>
> I apologize for taking this thread off-topic but I think that any library
> using a particular Unicode encoding for its strings should be exempt from
> the criticism that it does not have functionality dealing with converting
> between Unicode encodings.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Artyom Beilis
In reply to this post by Edward Diener-3
> From: Edward Diener <[hidden email]>
>
> > Okay. So that means people using  std::wstring have to deal with
> > converting to UTF-8 encoded std::string  on their own. Sounds like a
> > pain in Windows defaulted to use  std::wstring in applications. :/
> >
>
> Converting between Unicode  encodings should be a separate library anyway.
> Was there not someone working on  such a cross-platform library for Boost ?
> What happened to it ? Was it scrapped  because of possible Unicode support in
>C++0x ?

Accidentally (or not) there is a Boost.Locale library that I had submitted for a
formal
review is stuck in queue waiting for the formal review.

It supports charset conversions and much more of Unicode handling.

And accidentally (or not) it recommends using UTF-8 anywhere
and not to use wide strings...

 
http://cppcms.sourceforge.net/boost_locale/html/tutorial.html#1c383cd30b7c298ab50293adfecb7b18


Artyom


     
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123