RE: [boost] Re: Library Proposal: database (boost::db)
On Behalf Of Michael van der Westhuizen
Can you compae it with Database Template Library http://dtemplatelib.sourceforge.net/index.htm ?
Just an FYI here- I recently evaluated the DTL and it uses RTTI internally-
Thoughts on OTL?
I've used it a few times, and it's extremely capable.
Michael
Thanks for the link- that is very interesting. It looks like I can get what I need from it. IN rough comparison, it looks like the MYSQL++ library may be a bit more "normal" looking to DB developers who are used to disconnected recordsets, but it looks like the OTL libraries have far greater power. At the end of the day- I believe that a balance between "recordset"-ish model of MYSQL++ and the power of OTL would be a good combination. A library is not useful if it is too hard to get up to speed on OR too terribly different from what people are used to.
Hi, Brian Braatz wrote:
At the end of the day- I believe that a balance between "recordset"-ish model of MYSQL++ and the power of OTL would be a good combination.
A library is not useful if it is too hard to get up to speed on OR too terribly different from what people are used to.
Just to stirr up a little bit: http://www.msobczak.com/prog/soci/ This library aims at simple usage patterns, where intuitive and almost "embedded" syntax at at premium. A very different approach from those you discuss, but in fact complementary and can be merged with other approaches. (the code is to be modified a little bit, but what is available at the moment works fine with Visual C++ 7.1 and g++ 3.2) -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
On 2004-10-15, Maciej Sobczak <prog@msobczak.com> wrote:
http://www.msobczak.com/prog/soci/
This library aims at simple usage patterns, where intuitive and almost "embedded" syntax at at premium. A very different approach from those you discuss, but in fact complementary and can be merged with other approaches.
As someone who has used odbc, jdbc, dbtools, sqlapi, otl, occi, etc., this looks very nice to me. Further, the relative simplicity suggests it would be straightforward to implement for the leading databases. C++ really lacks a free, uniform, portable solution for rdbms access. Having like this library in boost would be *huge*, IMHO. One way to proceed might be to submit this a boost::db, while acknowledging that more sophisticated bells and whistles can be submitted separately later, either as enhancements to the base boost::db or as separate (but dependent) libraries. Steve
On Sat, 16 Oct 2004 23:35:37 +0000 (UTC), Steve Hutton wrote
On 2004-10-15, Maciej Sobczak <prog@msobczak.com> wrote:
http://www.msobczak.com/prog/soci/
This library aims at simple usage patterns, where intuitive and almost "embedded" syntax at at premium. A very different approach from those you discuss, but in fact complementary and can be merged with other approaches.
As someone who has used odbc, jdbc, dbtools, sqlapi, otl, occi, etc., this looks very nice to me. Further, the relative simplicity suggests it would be straightforward to implement for the leading databases.
I've added a page to the Wiki to record this discussion -- feel free to add your thoughts on the basic requirements there... http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da...
C++ really lacks a free, uniform, portable solution for rdbms access. Having like this library in boost would be *huge*, IMHO.
One way to proceed might be to submit this a boost::db, while acknowledging that more sophisticated bells and whistles can be submitted separately later, either as enhancements to the base boost::db or as separate (but dependent) libraries.
Perhaps, but it might not go well in the review process. I'd really like to somehow see the authors of DTL, OTL, etc come together and work on a boost proposal. Each of these libraries in my view brings something to the table -- including baggage. If we could get all the experts pulling together I'm sure they would produce something great for the larger C++ community in fairly short order. Jeff
First off, I haven't spent very much time with each library, and most of that was looking at the example code to try to understand what the interface looked like. So if I missed a piece of the interface, I apologize. Correct me. Maciej, I do have to say I am impressed with SOCI. It was really creative of you to step outside of the traditional DB library models and produce a clean and relatively straightforward interface. Unfortunately, from what I read, it only supports Oracle. I am not so impressed with DTL. That library has a number of good points, but the overhead of creating a "binding class" for each different recordset is a huge deal for me. That was my biggest frustration with both MFC recordsets as well as IADORecordbinding for ADO. Queries need to be quick to write and update. Having to edit the query and a binding recordset in a totally seperate file becomes unworkable. mysqlcppapi looks like a good, usable interface, but I question all the dynamic stuff running underneath. (Haven't looked at the code, just the samples to get a feel for the interface.) It really boils down to something that Jeff wrote about runtime enumeration of database schema's. Personally I haven't seen any application code that relies on runtime enumeration of the number of columns in a query and what types those might be. That is why I designed my library the way I did. (Jeff could you enlighten me with some examples.) I haven't looked at OTL yet. I will create a sourceforge account and post my database library as it stands right now. It definately is pre-alpha, but the core works enough to demonstrate the core interface I was going for. (Sorry all, I should have realized I'd need to do that before I even made the first post on this topic.) At this point I think we need to step back and start looking at some requirements for the library. My core requirements at the moment would be: 1) Works over ODBC. Expanding out to other DB API's would be great at a later point, but all the major DBMS's support ODBC, and it is available on both windows and *nix. 2) Ability to specify full queries and recordsets quickly, concicely and within a function. The overhead of needing to create new classes for each recordset is too high. 3) Integration with STL. Specifically iterators, typedefs and common functions (e.g. clear()). 4) Interface that is simple and understandable to programmers familiar with databases. (i.e. Users of the library shouldn't need to understand the intricacies of MPL, even if the library uses it.) I'll add these 4 points to the wiki. (Apologies to my lack of wiki editing knowledge, thanks to the person that reformatted for me. I will get it right next time, esp now that I know the wiki formatting commands.) Let's start to use that as well to store basic notes and requirements. Tito Jeff Garland wrote:
On Sat, 16 Oct 2004 23:35:37 +0000 (UTC), Steve Hutton wrote
On 2004-10-15, Maciej Sobczak <prog@msobczak.com> wrote:
http://www.msobczak.com/prog/soci/
This library aims at simple usage patterns, where intuitive and almost "embedded" syntax at at premium. A very different approach from those you discuss, but in fact complementary and can be merged with other approaches.
As someone who has used odbc, jdbc, dbtools, sqlapi, otl, occi, etc., this looks very nice to me. Further, the relative simplicity suggests it would be straightforward to implement for the leading databases.
I've added a page to the Wiki to record this discussion -- feel free to add your thoughts on the basic requirements there...
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da...
C++ really lacks a free, uniform, portable solution for rdbms access. Having like this library in boost would be *huge*, IMHO.
One way to proceed might be to submit this a boost::db, while acknowledging that more sophisticated bells and whistles can be submitted separately later, either as enhancements to the base boost::db or as separate (but dependent) libraries.
Perhaps, but it might not go well in the review process. I'd really like to somehow see the authors of DTL, OTL, etc come together and work on a boost proposal. Each of these libraries in my view brings something to the table -- including baggage. If we could get all the experts pulling together I'm sure they would produce something great for the larger C++ community in fairly short order.
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, 18 Oct 2004 21:04:05 -0400, Tito Villalobos wrote
I am not so impressed with DTL. That library has a number of good points, but the overhead of creating a "binding class" for each different recordset is a huge deal for me. That was my biggest frustration with both MFC recordsets as well as IADORecordbinding for ADO. Queries need to be quick to write and update. Having to edit the query and a binding recordset in a totally seperate file becomes unworkable.
I wouldn't dismiss DTL so quickly. The binding classes have their place, but I agree there is much that can be done without. DTL also supports a dynamic View...
mysqlcppapi looks like a good, usable interface, but I question all the dynamic stuff running underneath. (Haven't looked at the code, just the samples to get a feel for the interface.) It really boils down to something that Jeff wrote about runtime enumeration of database schema's. Personally I haven't seen any application code that relies on runtime enumeration of the number of columns in a query and what types those might be. That is why I designed my library the way I did. (Jeff could you enlighten me with some examples.)
sure. If you have any sort of select * then the result form will be determined at runtime. There's good technical reason to to this, in some cases, since it decouples the c++ code from schema changes. But it also becomes like programming with an "any" since you will need some form of runtime type information to have any type specific logic. Most common case that comes to mind is something that displays the query result as a table in a GUI or web page.
At this point I think we need to step back and start looking at some requirements for the library.
My core requirements at the moment would be: 1) Works over ODBC. Expanding out to other DB API's would be great at a later point, but all the major DBMS's support ODBC, and it is available on both windows and *nix.
2) Ability to specify full queries and recordsets quickly, concicely and within a function. The overhead of needing to create new classes for each recordset is too high.
3) Integration with STL. Specifically iterators, typedefs and common functions (e.g. clear()).
4) Interface that is simple and understandable to programmers familiar with databases. (i.e. Users of the library shouldn't need to understand the intricacies of MPL, even if the library uses it.)
One more-although I suppose it could be phase 2 is support for 'bulk update'.
I'll add these 4 points to the wiki. (Apologies to my lack of wiki editing knowledge, thanks to the person that reformatted for me. I will get it right next time, esp now that I know the wiki formatting commands.)
Don't worry about it - just copy by example. Also, you can't ever 'break it' because the last revision is still there if you need to revert.
Let's start to use that as well to store basic notes and requirements.
sounds good. Jeff
participants (5)
-
Brian Braatz -
Jeff Garland -
Maciej Sobczak -
Steve Hutton -
Tito Villalobos