|
Boost : |
From: Tito Villalobos (tvillalobos_at_[hidden])
Date: 2004-10-18 20:04:05
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_at_[hidden]> 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_Database_A
>
>
>
>>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
>
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk