Re: [boost] Re: Library Proposal: database (boost::db)

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-10-18 21:48:23

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