Re: [boost] Interest in an ODBC library?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-07-28 16:51:49

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Brian Braatz

> My goals:
> 1- functional drop in replacement for ADO recordset
> 2- Dynamic and static "views" and indexes
> 3- binding model that does NOT force you to use the bindings supplied
> with the library
> 	this is something ADO lacks, and something I have had to work
> around to great frustration
> 4- the ability to COPY from one table<> to another table<>
> 	* ADO does NOT ALLOW you to copy recordsets. (brilliant no?)
> 

Hi,

I've spent a lot of time developing a database library and a binding
language on top of it the past year and finally catching up on this
thread I just have to throw a few cents in.

1) Rather than basing it on ODBC, it might be nice to have a
boost::database library for which there could be multiple
implementations such as ODBC, (native) postgresql, etc...:

   boost::database d = boost::odbc::open(...);
   
   d = boost::postgresql::open(...);

   d = boost::msql::open();

ODBC is not always available or desirable.

2) With this done it's not too hard to write a non-intrusive DSEL for
binding on top of it.  I wrote one that supports dependent tables,
automatic mapping to STL containers, boost::optional, and common data
types like boost::posix_time::ptime.  A simple example of the language
might look like:

   table("customer") [

      *field("id")     = &customer::id,
      field("name")    = &customer::name,
      field("number")  = &customer::number,

      table("tax_exempt")[

         -field("customer"),
         field("state_id")   = &tax_exempt_data::state_id
      ]
      = &customer::tax_exempt
   ];

The structure customer has members id, name, and number.  The id field
is its key.  It also contains an optional tax_exempt structure that
resides in a table called tax_exempt and whose "customer" field is
related to the customer's id field.

Especially when dealing with nested data structures, the queries
generated by the library are far more optimized than what one could
easily write by hand, both for saving and loading.

3) On a bit of a tangent, it's also handy to have a DSEL for generating
SQL criteria strings.  It's so easy to make typos or forget 's on
strings:

   field name("name");
   field number("number");
  
      //s = "name = 'bob' OR number < 5";
   const string s = criteria(name == "bob" || number < 5);
   
If any of that sounds useful I'd love to help out.

Brock